- Special Edition Using Java, 2nd Edition -

Chapter 51

Using Roaster


by Luke Cassady-Dorion

There are multiple Java development environments that you could choose to work in. This chapter teaches how to use Natural Intelligence’s (NI) Roaster. Once you finish this chapter, you will fully understand all of the features that Roaster brings to the Macintosh. And once you become an accomplished Java programmer, this chapter should serve as a reference to you as you work with Roaster.

Introducing Roaster

NI filled a void in the Mac programming community when it released the Java Development Environment in January 1996. Previous to this release, Mac programmers wanting to develop in Java were unable to without jumping to other platforms. Roaster allows Mac programmers to create Java applets for use on World Wide Web pages. Roaster also allows for the creation of applications.

What Roaster Can Do for You

Roaster is NI's Integrated Development Environment (IDE) for the Macintosh. The program is a powerful tool for developing Java applet and applications on the Macintosh.

Java allows you to develop both applets and applications. Because these two are very different, it is important in our discussion that you use very clear terminology. Throughout this chapter, the word applet refers to Java applets, application refers to applications written in Java, and project is used when the comment applies to either.
 

Buzz words aside, Roaster enables you to create some very cool stuff. Java, unlike HTML, does have a steep learning curve, especially for new programmers. Roaster will do nothing for you if you cannot program in Java. There are plenty of good books out there on beginning with Java, and once you get the basics down, you already have the best book on intermediate to advanced development!

Developer Release Concept

The current release of Roaster is backed by an interesting concept. The release is considered a developer's release, which basically means a beta release that you have to pay for. In actuality, though, it is almost as if NI is preselling the actual release and then giving away the new releases for free.

Confused? When NI announced that it was developing this product for the Mac, there was a deluge of programmer requests to be on the beta list. Mac programmers everywhere were very eager to get their hands on this product. What NI decided to do, in quite a smart move, was to sell the beta CD with a subscription plan attached. For the initial purchase price, you are subscribed to a plan that provides, for free, all updates to the product up to and including the second commercial release. This plan has given Mac programmers the opportunity to work with a fast, graphical Java programming environment, months before other companies released comparable products.

Since the early release of DR1, NI has come out with DR1.1, DR2.0, and most recently DR2.1. The product is nearing completion, and a full release should hit the shelves in the next few months. DR2.1 brings significant features to the application that were sorely missing in DR1.0. Most notably,, DR2.1 includes source-level debugging and support for the full Java API; DR1.0 did not offer any sort of .net or audio support, which was a big annoyance. Additionally the fact that source-level debugging was not added until recently was a major cause of delays in projects; println debugging is just too time-consuming.

You should note that the purpose of this chapter is not to provide a comparison between Roaster DR1.0 and DR2.1 but, rather, to introduce DR2.1 as an independent product. If you have the first edition of Special Edition Using Java, you will definitely notice a difference between what I introduced as Roaster’s offering then and what I cover now. Judging from the rate at which NI has turned out fast, efficient code, it is safe to say that the engineers have seen little of their homes since this project was announced.

As I stated, DR2.1 is very near a commercial release. It does have its faults, however. These faults are quite limited and do not in any way make Roaster an inferior product. In fact, it is my opinion that Roaster is the best development environment available for the Macintosh at the moment. The faults can be grouped into two distinct categories:

One place where the IDE can use some improvement is in its inability to split the main window into more than two horizontal panes. Release 3.0 promises to allow for unlimited horizontal and vertical window dividing, so this problem will be fixed soon. The other UI improvements that you see involve features such as more toolbox utilities (yes, they have even more ideas up their sleeves) and a more customizable interface as a whole. There are also rumors that NI will release a third-party API for enhancing the IDE, similar to what is done by other major vendors.

See “Interpreters and Compilers,” Chapter 39 for more information.
 

The other areas in which Roaster is lacking is in regard to a JIT, a native compiler, and also visual tools. While these all sound like major issues, the first two are greatly offset by the shear speed of the Roaster VM. Because javac is written totally in Java, its speed is directly related to the VM under which it is running. NI has done a terrific job in getting its VM to operate at top speeds and, therefore, can take some extra time with its native compiler and JIT.

Visual tools are another story; this void exists for the entire Mac platform. As I see it, this is a major void. In the rapidly changing computer industry developers need tools that help bring products to market yesterday. Visual tools do this by taking care of most of the repetitive coding that a project might entail.

Enough about the bad parts of Roaster—let’s dive into this shining product. Every product has its faults, and these faults must be addressed, but NI has developed a product that offsets its own faults with some terrific features.

Installing Roaster

The current version of Roaster is Developer Release 2.1.

As is the general case in the computer industry, information is current for only about 10 minutes. This text is based on Developer Release 2.1 of Roaster and press releases at this time of writing. Roaster Release 3 is expected quite soon, and Roaster Pro is expected out in the fall of 1996.
 

This version, however, is not the one that was mastered on the CD. The CD ships with Version DR2.0, and the update is available from NI's Web site at http://www.roaster.com/pages/products/roaster/updates/update.html or by contacting them at (617) 876-4876. To install the CD, drag its contents to your hard drive, and then move the scripting additions to the Scripting Additions folder that should be in your extensions folder.

Notice a variety of free software that NI has bundled in on the CD. None of this software is required to run the program, but some is quite useful. This chapter, in fact, was written using BBEdit. Some other cool products on the CD are the tools for database interaction.

Next, restart your computer and then Roaster is ready to go. If you are having trouble running Roaster, make sure that you copied all of the files shown in figure 51.1


FIG. 51.1

Note the distribution of the files. Of note is the scripting extensions in the system folder. If these files are not placed where they belong, some toolbar utilities which rely on their location renaming constant will fail.

The Roaster Interface

After the programming geeks develop an application, the information system geeks take over and shape the product’s interface into one which users feel comfortable working with. In developing the product, NI was well aware that an interface can make or break a product. All commands are easy to locate and not masked with confusing names.

Introducing the Integrated Development Environment

Unlike the Java Developers Kit for the Mac, Roaster is a complete IDE; this involves a combination of a powerful text editor, interpreter, and compiler all in one. Roaster also bundles a debugger with its environment.

The IDE that NI has created for Roaster integrates a version of its powerful QuickCode Pro editor with a suite of Java development tools. These tools include the Sun javac compiler and also its own compiler. The combination of these two compilers provides for increased user flexibility. The Java developer can opt to choose from two compilers:

To switch between the two compilers, choose Edit, Preferences, and then click Compiler. A dialog box appears, as shown in figure 51.2.

Roaster still classifies its compiler as “icky” and recommends that, for the time being, you use Sun’s compiler.
 


FIG. 51.2

NI combines two compilers with its development environment.

To manage an increasingly large amount of project files, Roaster incorporates a hierarchical project manager system. This system displays all project files in a window that supports a drag-and-drop interface. This feature enables you to add files to the project simply by dragging them to the project window. You will find this especially helpful as your projects grow and begin containing many project files.

The Roaster interface puts development tools right at your fingertips. Roaster’s versatile code editor supports multiple clipboards; you will find this extremely helpful when managing code snippets.

Most Roaster menu commands have associated keyboard shortcuts, thus cutting down on the annoying keyboard-to-mouse exchange that often bothers programmers. In fact, the IDE is so configurable that it allows you to reassign any keyboard shortcut already assigned by the product when it was shipped.

Roaster's Special QuickCode Pro

With Roaster, NI includes a special version of QuickCode Pro—its popular code editor. That statement is actually a bit of a stretch. When Roaster was still around DR1.0, the editor was referred to as a Java-tized version of QuickCode Pro, but Roaster has grown so much since DR1.0 that it is almost a totally different product. As I detail later in the chapter, NI has brought many new UI features to the editor. These new features are detailed in the coverage of the toolbar.

The editor supports syntax coloring for both Java and HTML keywords, as well as brace flashing to notify a user instantly if a brace has been accidentally omitted. Take a look at figure 51.3. This window shows an applet that you will be developing later in the chapter.


FIG. 51.3

Note how the code editor deals with your code. Special words are colored, and new sections are automatically indented.

Note how the editor deals with the code. The colors and text style used for special words are configurable by choosing Edit, Preferences, and Text Styles. It is possible from this section to turn off syntax coloring and also to set the display font, color, and style.

The editor does not begin any sort of syntax coloring until after a file has been saved. If it is saved with a .java extension, then Java-specific syntax coloring will occur. If it is saved with an HTML extension, then HTML-specific syntax coloring will occur.
 

 

While it is possible, there is no real reason to turn off syntax coloring. If the preset colors bother you, feel free to adjust them. Once you become accustomed to the colors, you will catch code errors much faster.
 

Using QuickCode Pro's Toolbar

One of the code editor's most useful capabilities is its customizable toolbar. The toolbar includes a method browser, two powerful find utilities, bookmarking utilities, and a quick-commenting tool. The toolbar also allows for complete control over both named and unnamed clipboards, code balancing, auto formatting, both predefined and user-defined macros, and text shifting.

It also incorporates support for mulitplatform file formats. Included is a wizard tool that creates dummy signatures for classes and methods. There is even a tool that allows you to automatically mail—via Eudora—a chunk of code to someone. For a quick reference, online help is accessible from the toolbar. There is even an integrated suite of HTML editing tools that are similar to those provided by BBEdit. Control over the toolbar was designed with human-computer interface guidelines constantly in mind.

While it is hard to believe that you might want more from an IDE, this opportunity could arise. For this reason, NI has developed Roaster with full AppleScript and Frontier support. Thus, you can easily write in features that you might desire.
 

The method browser is a pop-up menu that, when held, down-displays a running total of all methods in the current window. The methods are displayed using the convention class_name.method_name. Again, as your projects begin to grow, this tool will prove invaluable. Figure 51.4 shows how the method browser displays the available methods. To go instantly to a specific method, simply choose the method from the pop-up menu.


FIG. 51.4

The method browser provides a hierarchical list of all methods that you have developed so far in the current file.

The two find utilities included are Quick Find tools for locating repeating occurrences of a string. A Zip Find tool is included for more advanced searching capabilities. To use the Quick Find tool, simply highlight a string in the development window and then click the Quick Find icon. This will search from the current selection to the bottom of the file. To search from the current selection up to the top of the file, Option-click the Quick Find icon.

The Zip Find utility allows for some more advanced searching techniques. To use this tool, choose Configure Zip Find from the menu accessible under its icon in the toolbar. When prompted, enter a search string. In addition to entering a search string, the Zip Find tool allows a variety of search options to be configured from this menu. Clicking the OK button causes the Zip Find menu to update itself and contain a listing, by line number, of all occurrences of your string. Figure 51.5 shows how the code editor brings you instantly to the location of a string occurrence.


FIG. 51.5

Selecting a found word from the menu instantly highlights its location in the text.

The search criteria feature is also added to the pull-down menu to accommodate repetition of this task. To go to an occurrence of the string, simply select it from the pull-down menu. To perform search and replace commands, choose Search, Find. This menu has more complex searching capability.

To accommodate quick movement to parts of your code that are commonly referenced, you can add jump points with the Bookmark tool. Just select the location in your code that needs to be bookmarked, and click the bookmark icon.

The paper clip, which appears over the icon, indicates a bookmark has been added. Option-clicking the bookmark icon will void its link.
 

The number of your project's bookmarks is limited only by your system's memory. See the end of this section for more information on customizing the toolbar.

Java supports multiple styles of commenting: one for individual lines, one for blocks of text, and another that is used to develop documentation. You can control these first two types of commenting via the toolbar. If you want to comment out a single line of text, place the cursor at the start of the text and click the comment icon. Option-clicking the icon while you have a block of text highlighted will comment out that block as a whole.

Two toolbar utilities that you will no doubt use over and over are the named and unnamed clipboards. These utilities allow for the intelligent management of multiple code snippets. Figure 51.6 shows the clipboard utility as it manages multiple code snippets.


FIG. 51.6

New text is added to a clipboard. You find that all other tools available to the clipboard utility very helpful when managing the large projects.

Named clipboards are used more when dealing with commonly used code. To load something to a named clipboard, select the text. From the named clipboard, choose Cut or Copy, then New. The editor then prompts you for a name for this code. The code can now be referenced by name from the named clipboard pull-down menu. These snippets are in range for the entire project, thus you can copy and paste between project windows with ease.

The unnamed clipboards are used more for code that will be accessed only a few times. To load code into these clipboards, select the code and use the standard clipboard management tools, just like you did with the named clipboards under the unnamed clipboard pull-down menu. When a unnamed clipboard is storing data, its icon changes to a clipboard with a piece of paper attached. These clipboards also have a range of the entire project. In addition to the standard suite of clipboard commands, added support exists for some advanced commands that you will find helpful. Take a moment to familiarize yourself with these menu commands; again, you will find them very helpful.

Of course, you can use the traditional clipboard commands from the Edit menu. These are useful for interapplication text manipulation.
 

Locating a missing parenthesis, brace, or bracket can be a programming headache, especially as the wee hours of the morning approach, when your eyes can blur everything together. The code-balancing utility will test for matching parenthesis, braces, and brackets. As methods become more developed, this utility will become more helpful. To take advantage of the utility, place the cursor at an open-section marker. When clicked, the utility highlights the text as far as the corresponding close-section marker.

I take advantage of this tool so much that I have mapped it to the F2 key. This is really great, as it cuts down on the keyboard-to-mouse movement that can slow me down.
 

Some of you might remember programming with an early development tool for the Macintosh called True Basic. It was not a very powerful tool, but it did have a utility called Do Format. Do Format would look over your code and format it to make it prettier. Every block of code would get indented, and keywords such as Do and While would be matched up properly. The one big disadvantage was that the code was formatted according to True Basic’s hard-coded specifications.

NI’s auto-format tool does pretty much the same thing for Java that Do Format did for True Basic. It allows you to select a block of code and, when you click the icon in the toolbar, the code is formatted in one of the popular Java/C formatting styles. Unfortunately, these styles are not definable, and if the tool attempts to format your code in a way that you do not like, then you are out of luck. Because only about four popular formatting styles exist, I would like to see NI offer the user the ability to at least choose between these four styles.

Because of the syntactical similarities between Java and C, the formatting tool will work for both Java and C.
 

As the number of Roaster projects worked on increases, the amount of code that is repeated also increases. These codes can range from standard comment headers to developed event loops. To accommodate this amount, the toolbar can take advantage of macros.

Macros are definitely a very cool utility. I take advantage of macros by building them around all of my commonly used methods. I then never have to retype them! I also program basic method frameworks to macros and then only have to modify them to create new methods. Remember that macros stay in range for any project that you develop. Therefore, unless you delete them, macros are around forever.
 

To define a macro, select the text in your code that will be reproduced , choose Macro, New Macro, and then enter the text of the macro into the window that appears. You are presented with a dialog box that asks for a macro name and identifier. The name is displayed in the macro menu. The identifier is used to reference the macro in other macros, giving you the ability to create nested macros.

To use a macro in your code, either choose the macro by name from the macro menu or assign a keyboard shortcut to it. You can assign a keyboard macro by selecting Configure Hot Keys in the toolbar. Figure 51.7 shows how to accomplish this.


FIG. 51.7

Adding keyboard shortcuts to functions that are commonly used can help increase productivity. I use them to automatically drop in overused parts of code.

Select this menu item, click the macro name from the menu that appears, and then press the hot key combination you want to associate with the macro. In addition to user-definable macros, a set of built-in macros exist, which include Date, Time, User name, and Window name. You can modify the macros’ names by choosing Macro, Macro Options.

When code demands the addition of a new loop at the center of the method, programmers who use proper formatting techniques will indent the code one tab stop. A shortcut to moving code a tab stop to the right or left is selecting the code and clicking either the Shift Left or Shift Right icons. I actually tend to move my code around a lot and have mapped these two tools onto the F3 and F4 keys for even faster access.

Java's cross-platform nature can lead to a situation in which code that you wrote on one platform might be compiled on a different platform. This situation can cause problems because Macs, UNIX systems, and Windows-based systems all treat text files in a slightly different manner. To accommodate these differences, Roaster has added the File Format utility to the toolbar. This utility brings up a menu that allows you to select your code's format.

As I stated earlier, I program frequently used chunks of code into macros that I then make accessible from the keyboard. Since the release of the wizard tool, I have removed two macros from my ever-growing stash. The wizard tool throws dummy signatures into your project whenever you need them. Placing a new method or class signature into your project is a simple task of positioning your cursor where you need the signature and then selecting either Class or Method from the wizard pull-down menu. To expedite this process, I have mapped each of these tasks to a the F6 and F7 keys. My hands never have to leave the keyboard!

Many of the of new toolbar utilities have been written in AppleScript. The Wizard Tool is one of them, and it requires that you have properly installed all of the Scripting Additions that were shipped with the CD. If you select New Class or New Method and nothing happens, then double-check that the Scripting Extensions are properly installed.
 

Another really helpful utility added to the toolbar stash in DR2.0 is the ability to e-mail a chunk of code to someone else. For example, if you are having trouble getting some code to work properly and you want to mail it to a friend or coworker to look over, all you need to do is select that code and click the Mail icon in the toolbar. You are prompted for a To address (which, by default, is the java-mac listserv), and then your message will be off.

Like the previous utility, this utility is also written in AppleScript. In fact, it is scripted to work directly with Eudora; therefore, if you use Emailer or some other mail client, then you are out of luck. You will have to wait until this utility is rewritten with a direct SMTP interface.
 

If you are at all like me, then you always have some sort of reference sitting in your lap while you are developing. I have memorized a large portion of the Java API, but there are many areas that are a little gray to me. While many commercial references are on the shelves, I find that the information contained in each is pretty much the same. A book can outshine another with regard to its index. If I am in the middle of some development, I want the information fast. The index is the tool that makes the information available quickly.

Of course, even a great index cannot eliminate the time that is required for a human to look up the information and search for it in the book manually. For this reason, electronic searching is an even better tool. To facilitate quick electronic searching, NI has published the Java API in Altura’s QuickView format (users of CodeWarrior will be familiar). NI has even gone the extra mile and provided detailed explanations of the more popular classes.

Now you are probably asking, “How does electronic searching integrate with the toolbar?” The documentation is linked to the toolbar and provides two ways that you can search out information:

Finally, NI had integrated a suite of HTML-stylizing tools into the toolbar. These four tools allow auto-placement of most of the popular HTML tags. While NI does not attempt to move Roaster so that it is competitive with a commercial WYSIWYG HTML editor., it does add functionality at about the same level provided by BBEdit. It is nice to not have to switch into another application if you want to develop the Web page that will serve your Java applets. You should note that once the HTML file is saved with an HTML extension, it will support HTML-specific syntax coloring.

While many toolbar utilities are included in the default toolbar, the HTML ones are not. You have to manually add in the ones you need.
 

To recognize each icon's command, place the mouse over the icon. A small help box appears to give the utility's name. This is true for all toolbar utilities. You also can display the utility's name in the toolbar, if you would prefer. Note how the first method is being performed in figure 51.8.


FIG. 51.8

If you are as absent-minded like myself, you are probably constantly wondering what all of the icons do. Holding your mouse over any one icon for a second or so displays its function.

To configure the toolbar, choose Configure Toolbar from the pull-down menu that appears from the NI icon on the top-left side of the toolbar. The configuration window displays a scrolling list of all toolbar utilities and a picture of the current toolbar.

To add a new icon to the toolbar, simply drag the utility name to the toolbar. The utility is displayed as either text, icon, or both (depending on user selection) in the toolbar. The individual entries can be dragged into any order the programmer finds useful.

To remove an icon from the toolbar, simply drag its entry to the trash can icon, which is displayed conveniently in the toolbar configuration window. Figure 51.9 shows all of this in action.


FIG. 51.9

Configuring the toolbar is as easy as dragging and dropping the desired utility onto the toolbar—if programming were only this easy.

Didn't I say that NI went all out with its human-computer interface implementation? The toolbar allows for multiple instances of a single utility; this is helpful, especially when defining a series of clipboards to organize your code. A scrolling system is established to accommodate more entries than will fit in the toolbar.

For a description of each toolbar utility, click its entry in the configuration window.
 

The Audio CD utility enables you to control your audio CDs while engaging in long, Java-enhanced coding sessions. It is always part of my toolbar; in fact, I hooked up my stereo to the audio out-ports on my computer!

The IDE Windows

The Roaster IDE uses a Project Manager window to organize the files that your project uses. To start a new project, choose Project, New Project. The current release of Roaster requires that all projects use the project_name.[pi] naming convention. Also, if you are developing an applet with your project, Roaster requires that the class extending java.applet.Applet has the same name as the current file name.

The Project Manager supports full drag-and-drop capabilities. To add a file to your project, simply drag it from the finder to the Project Manager window. The project manager automatically groups—under unique headings—all files in your project by package. Next to the code's name in the Project Manager window is a pop-up menu that appears, using a hierarchical menu system, the name of all classes and their associated methods. This display is shown in figure 51.10.


FIG. 51.10

Choosing a method in one of your project files is as easy as selecting its name from the pop-up menu.

Your First Roaster Project

While the scope of this chapter by no means includes teaching Java, it is important to step through a sample project to show how one would build an applet or application with Roaster.

Developing an Applet

To launch Roaster, double-click its icon in the finder. This brings you into the Roaster IDE. The IDE includes all tools necessary for developing the project itself.

To actually view the applet, it is necessary to use the Applet Runner. This application is automatically launched when you attempt to Run your project from within the IDE.
 

Choose Project, New Project (when prompted). Create a new folder for your project, and then enter a name for your project and save it in the folder that you just created. For your sample project, use the name helloAuthor.[pi]. Creating a new project brings up the Project Manager window (for more information about the Project Manager, see the previous section, “Your First Roaster Project”). A new project contains no files; as you build your project, you will add to this window.

Create a new file by choosing File, New. Into this new window, enter the following code:

import java.awt.Color;
import java.awt.Graphics;
import java.awt.Font;
public class helloAuthor extends java.applet.Applet {
String greeting = "Hello Luke";
Font myFont = new Font("Helvetica", Font.PLAIN, 24);
public void paint(Graphics g) {
g.setFont(myFont);
g.setColor(Color.magenta);
g.drawString(this.greeting, 10, 50);
}
}

As you enter the code, notice how it changes color. As you become familiar with the Roaster environment, you will begin to know which words change color and which do not. This feature is extremely helpful for finding typographical errors as you generate code.
 

Now that you have entered the text, choose File, Save. When prompted, name the file helloAuthor.java and save it in the same folder as your project. At this time, Roaster requires you to name your source file with the same name as your class. It also requires the source files to be in the same folder as the project. Choose Project, Add Window. This action adds the file to your Project Manager. Of course, you could drag the source file into the Project Manager yourself.

Now that you have a complete project, choose Project, Compile. If you have no errors, Roaster adds a file to your project folder with the .class naming convention. This file is your bytecode and can be distributed for viewing on many Web pages. Unless you are terrible satisfied with this chapter and want to say “Hello” to me all over the Internet, I am sure that you will not want to place this applet on your Web pages.

To view your applet, one more element is still necessary: the HTML code that defines the layout of your page. Fortunately for us, when we created the new project, a file called example1.html was added to our project. This file will call an applet whose name matches the name of the project itself (of course, the .class is added to the end). If your applet is titled the same as your project and you are happy with a HEIGHT parameter of 100 and WIDTH parameter of 300, then you can simply select Run from the Project window and take a look at the stunning new applet that we have created. Of course, if you need to modify any of these settings, just double-click the example1.html file and edit away.

The first time you run the Appletviewer, a window with Sun’s licensing agreement will first pop up. Click Agree to continue. If you don't see the Agree and Reject buttons, resize the window by clicking in the zoom box at the top right.
 

The preceding HTML is obviously quite minimalistic is because the Applet Runner will only interpret the <applet> tags, and it is not a complete Web browser. There obviously is no need to place any other miscellaneous HTML around the page. The file needs to be saved in the same folder as your project, and it must be named example1.html. This file name requirement was hard-coded by Sun, and NI plans to allow for any HTML name in the future.

Now you are ready to check out the applet. Figure 51.11 shows what the final output for the applet is.


FIG. 51.11

Once you get the applet up and running, you should see output similar to what is pictured here.

Choose Project, Run, or drag the HTML file on top of the Applet Runner to launch that application. Assuming that everything has been entered correctly, there should be a magenta-colored greeting directed toward me in a gray-colored box.

Developing an Application

As previously stated, the DR2.1 release of Roaster will not compile stand-alone application into native code.

Roaster Pro (available fall 1996) will allow you to compile your application into code that is native to many platforms. Think of how easy it will be to develop cross-platform products in the future!
 

It is, however, quite possible to view Java applications with the Applet Runner. Now close your current project and create a new project. Create a new document, and enter the following text:

class heyLuke {
public static void main (String args[]) {
System.out.println("Another exciting creation");
}
}

Save the file as heyLuke.java and add it to your Project window. Before you can run the application, you need to tell Roaster that your file is an application and that it should be the startup file.

For some reason, Roaster does not allow the user to select between an applet project and an application project when creating a new project. For this reason, even if you are developing an application, Roaster will still add an HTML file to the project. While this is an annoyance (especially if you primarily do application development), all you have to do to remedy the solution is highlight the file and select Project, Remove Files.
 

To indicate that heyLuke.java is your startup file, highlight it in the Project window and choose Project, Set Startup File. Notice the arrow that now appears next to the file name. More kudos to NI's adherence to human-computer interface guidelines.

Now that the file has been ear-marked as your startup file, you are ready to run the application. Choose Run from the Project window, and what do you know? More fun from the Java department. The output for this application is shown in figure 51.12. Try playing around with the application a little. Can you make it output the text in color? If not, don’t worry. By the time you finish this book, you will be able to do anything that you want with Java.


FIG. 51.12

This is the output for our complex application.

Applets Versus Applications

The decision on whether to develop an applet over an application depends on the scope of your project. Often a project can seem to exist in both the applet/application categories. In fact, sometimes two versions of a project will be developed. Because they do not require a Web browser interface, applications allow for greater flexibility. The security issues that an applet possesses do not exist with application development. As you become increasingly familiar with the language, it will become much easier to decide which route your projects need to take.

Roaster's Capabilities

Since the DR1.0 release, Roaster has added a lot of new features. These features are greatly appreciated, and Roaster developers should be very excited about what NI will roll out in Release 3.

Roaster's Java Support

Currently, Roaster supports only the JDK Version 1.02. At the time that this book is being written, Version 1.02 is also the current version of the JDK. In the fall of 1996, Sun will release the JDK 1.1, and NI will, no doubt, offer support around the same time.

While Roaster supports the JDK version 1.02, some problems remain regarding the .net class and display of JPEGs. The .net class works 100 percent of the time when making socket connections to the same machine, but if you attempt to make connections to another machine, you will have trouble.

Additionally, Roaster will not display JPEGs at all—only GIFs.

For many developers these restrictions are far from limiting; one can develop a complex project with Roaster. However for developers who need the functionality of the .net class, there are some issues that NI will have to clear up before a serious commitment can be made to the product.

While Roaster does not support some aspects of the current specification, it will still generate proper bytecode. Thus, you will be able to run the project through a VM that does have full support.
 

The restrictions the Mac OS places on Roaster are possible to override, but doing so is not desirable for Mac programmers. Doing so means overriding many toolbox calls, which can make the program highly incompatible with future releases of the system software. If you have never programmed for the Mac before, the toolbox might be something new to you. The toolbox contains a series of methods that deal with the Mac's graphical interface, memory management schemes, and other Mac-specific stuff. Java supplies its own methods for dealing with these situations, including the Abstract Window Toolkit (AWT). Thus, a Java programmer does not need to bother with toolbox calls. All translation to the Mac interface is taken care of by the folks who write the Applet Runner software.

Currently, the Mac OS requires applications to have a standard look and feel. Roaster's Applet Runner does a great job of making Java projects conform to that look and feel. For example, the AWT lets users create text areas of varying background color. On a Mac, text areas are always white; thus, any calls to change a text area's background color are ignored. Also, it is obviously a rare occasion that, on a Mac, pop-up menus will appear in a font other than the preset system font. Roaster's Appletviewer will conform to this by not interpreting any attempts to change the menu font. Java also allows for a Windows/ UNIX feel by supporting window iconization. This will not occur with Roaster's Appletviewer. Any programmers wanting to develop for the Mac, even in Java, should familiarize themselves with the Mac toolbox. Apple's “Inside the Macintosh” series is a great resource for toolbox programming.

Applet Support Versus Application Support

Currently, much of the hype surrounding Java development is related to applet development. However, Java's application-building qualities are perhaps even more powerful. It is possible to develop applications that, for example, dynamically update themselves over their network. A company never needs to worry that a staff member might not be using the latest version of a software product. It is estimated that companies spend millions of dollars just in physically making sure that all products are kept up to date. As a Java programmer, your applications—if they support this capability—will have a much higher selling value.

Roaster currently supports a minimal version of application development. Roaster Pro will allow for complete stand-alone application development. This development includes pure bytecode development and also native code development for multiple platforms.

To write an application with Roaster, develop your source code in the traditional manner. Then, in the Project window, highlight the file that contains your main() method, and choose Project, Set Startup File. When you run the application, the Appletviewer can interpret your code properly.

Debugging Your Code

Of all the hours that you will spend working on code, most of your time will be spent on debugging. This might range from finding a missing semicolon (my favorite), to dealing with incorrect variable handling. Finding errors in Java-based projects is, for the most part, much easier than in projects developed in languages such as C++. This ease is mainly because of Java’s strong type-checking that catches most errors at compile-time instead of runtime. There are plenty of situations where you will not be able to troubleshoot your code merely by examining it, and you will need to turn to a debugging utility.

In the development of Roaster, NI opted not to include Sun's dbx debugging library and instead decided to develop its own graphical debugging environment.

To work with the debugger, a .class file must be developed first. This means that unless you are able to work out all syntax errors and get the code to compile correctly, you will not be able to use the debugging tool.

To run the debugger, open the project on which you will be working. If you have not already compiled the code, now is a prime time to this. As stated earlier, the .class file is required for the debugger to run. Once the project is open, choose Project, Enable Debugging.

Note the check mark that appears next to the debugger menu option; this indicates that the debugger will take over operation once the project is run.
 

Notice that your code has been shifted to the right about 1 cm, and there is now a thin, gray line running down the page. You can click to the left of the line to set a debugging breakpoint. Figure 51.13 shows a project being debugged.


FIG. 51.13

NI’s debugger enables you to step though your project, tracing the path of a variable.

A breakpoint is the point in a project where the debugger will automatically pause execution.
 

To set the breakpoints for the .class file, just open up this file and insert them in the fashion described previously. If you are totally unsure where to set your breakpoints, there is a suite of tools that will help you locate the problem. These tools are displayed on the toolbar that is displayed when the debugger is fired up. Let’s fire up the debugger and look at a program.

Choose Project, Enable Debugger, Run. The debugger now displays your project with a small, green arrow next to the first instruction in the code. The debugger only executes a line of code when you give it permission. This is quite helpful, as you are able to step through the program and trace exactly what happens line by line. If errors are deeply nested within the program, this process can be rather tedious—you might want to have a hot pot of Java sitting at your side! The Debug toolbar displays a series of icons that allow you to control the execution of the program. One other window that you might want to bring up at this point is Windows, Current Object Inspector. This window displays the values of the instance variables of the current object.

From this point, there is a variety of options that you can use to take over program control.

Clicking Run executes your code up through the point where either a breakpoint occurs, the program terminates, or the program crashes. If you already have a good idea of where your program is causing errors, you might want to place a breakpoint before that line and then execute the code until you encounter the line.

You probably don't know where your code is beginning to generate errors and will want to start with another one of the tools.

The Step Over button executes your code one line at a time. This button is very useful (and sometimes tedious, if you have to step through hundreds of lines of code) for tracking the exact values of instance variables.

If, in your trace through the file, you encounter a call to a subroutine, the Step In button moves the trace into the subroutine. If you are tracing through a Java source and encounter a subroutine for which only the bytecode file is available, you will be thrown into that file.

To move out of the subroutine and continue the trace at the source of the call, click the Step Out button.

Clicking the Step Out button does not exactly cause the program to jump back to the source of the call. The subroutine's execution is finished. Thus, any computations performed on variables are still in scope.
 

The Step Over Continuous button is basically the combination of the Run and Step Over buttons. Basically, this button runs through your program line by line but never steals control away from the user.

While the Run button only stops program execution when it hits a breakpoint, it is possible to stop this operation with the Stop button on the debug toolbar. If, in the course of this operation, your code involves a call to a subroutine, the debugger does not show what is happening in that call. The subroutine is, of course, still be executed, but this will all happen behind the scenes.

If your debugging needs involve the examination of all subroutines, the Step Into Continuous button will bring you through all subroutines one line at a time. Again, the Stop button pauses the execution at that current line of code.

If during the course of your debugging, a sudden flash of brilliance tells you the source of your error (or if you just figure it out), clicking the Kill button returns you to the text editor. Remember that once the debugger is enabled, it must be manually disabled for normal execution.

Where Roaster Is Going

As is obvious, Roaster is quite an advanced program. It does have a way to go, but the developer release program makes your investment well worth it. Release 3 will bring support for the full Java API, and soon after you will have Roaster PRO that will cater to application developers. The end of 1996 promises to bring a lot of cool tools to the Mac, and developers should be very excited.

NI is also to be commended on its technical support; a post to their mailing list at java-mac@natural.com is usually answered by a competent staff member within 10 hours. When I first started using Roaster, I was constantly posting questions to the group, only to have my problems solved right away!


Previous Page TOC Next Page

| Previous Chapter | Next Chapter |

|Table of Contents | Book Home Page |

| Que Home Page | Digital Bookshelf | Disclaimer |


To order books from QUE, call us at 800-716-0044 or 317-361-5400.

For comments or technical support for our books and software, select Talk to Us.

© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company