VisualAge for Java Professional
Written by Gordon Zeglinski
This article will look at IBM's newest member of the VisualAge family, VisualAge For Java. To evalute the product, new code was developed and existing code was imported. Before we get into the nuts and bolts of the package, let's quickly review what is included out of the box.
With a suggested retail price of $99, VisualAge For Java (VAJava) Professional ships with 3 CDs. One CD for each for the OS/2 and Win32 based environments. The third CD includes an interactive tutorial introduction to Java programming with VisualAge. According to the box, you will need at least a Pentinum with 32 megs of ram (48 megs is recommended) and about 100 MB of free drive space (70 for a full product install and 30 for swap file). VAJava will run under OS/2 Warp 4, Windows NT 4.0, and Windows 95.
I used a Pentinum 133 MHz with 48 megs of ram running Windows NT 4.0 with service pack 3 installed. I did not have time recover from a failed attempt at applying a CSD to Warp 4 in order to test under this environment. This configuration is adequate for running the product, for most uses. As we'll see later, under certain circumstances more memory is needed for adequate performance.
Without further ado, we'll start by looking at the included tutorial.
The tutorial was created by MindQ and requires Windows to run. The tutorial covers many aspects of the Java language in general and of VAJava in specific. The tutorial contains several tours, a list of internet resources that can be consulted, sample applets, a FAQ, and a list of Java language keywords. The tutorial application is easy to use. Most of the information presented is aimed at people that are either beginner programmers, unfamiliar with object orient programming, or have no experience in Java. The tutorial also covers the basics of using VAJava. Programmers familiar with VisualAge C++ will find it easy to jump right into using VAJava without looking at the tutorial.
VAJava contains an integrated debugger, version control system, and graphical GUI design interface (the visual builder). It supports JavaBean development, RMI, and of course "regular" Java application development. With patch set 2, it's compatible with version 1.1.2 of Sun's Java Development Kit (JDK). As a bonus, JGL (a library of generic collection classes) by ObjectWorks is included with VAJava.
VAJava is written in Smalltalk. No doubt, this is primarily responsible for sometimes sluggish performance and relatively high memory requirements. I recommend 64 megs of ram if you want to use the JFC within this version of VAJava.
Development in VAJava is not file based. More precisely, two main files hold the code known to VAJava. The main file stores the configuration information, and most recent code modifications. The second file called the repository contains older versions of code. These older versions can be saved by the programmer or automatically by VAJava. In order to use any code outside of VAJava, it must be exported. The programmer can choose between exporting Java source code, class files, or Jar files. In order to use any third party code within VAJava, the programmer must import the code. VAJava can import the same file formats as it can export. The downside of importing lots of code is that the performance of VAJava decreases. Using the JFC as an example, the workspace file grew to just under 24 megs from just over 7 megs. Similarly, the runtime memory requirements (including that of NT) went from about 60 megs to about 72 megs. Performance was significantly impacted by lots of swapping. It is also worth noting that the JFC took more than an hour to import.
On-line help is written in html files. A http based html search engine is included. The upside of this approach is greater flexibility. The downside is that the system has to support the demands of a WWW browser in addition to those of VAJava. Sometimes finding information in the on-line help is difficult. When found, the instructions are detailed and sufficient to guide the programmer to complete the task in question. Overall, the on-line help is good. I would like to see a "giant how-to section" added to make finding information on specific tasks quick and easy.
Now that the basics have been covered, let's get right down to how well VAJava looks and works.
Figure 1 shows the Workbench in projects view. About 90% of the time, the Workbench will be used in projects view. Every project contains one or more packages. Each package contains one or more classes (or interfaces).
Figure 1: VAJava Workbench.
In Figure 1, the class ClockLED is highlighted in the upper pane. The lower pane shows the class definition for ClockLED. Similarly, if a method was highlighted in the upper pane, its definition would be shown (if possible) in the lower pane.
Although the workbench can be used to make code changes, most of the time is spent in the visual builder, method browser, hierarchy browser or Beaninfo page. Each of these sections allows the programmer to work on specific areas of the code. We will look at some of these areas.
The Visual Builder
The visual builder window is shown in Figure 2. By selecting the tabs for "Methods", "Hierarchy", etc. the programmer can quickly change between editing windows.
Figure 2: Visual Builder.
The application in Figure 2 is a test applet used to illustrate how VAJava handles the lightweight AWT controls, LED and ClockLED. It is noteworthy to point out that the visual builder allows additional control types to be added to its palette and allows these controls to draw themselves within the builder. Figure 3 shows a more complicated applet. This applet represents a typical "logon prompt".
Figure 3: Logon Applet.
In the logon applet, we do not want the user to attempt a logon until both a user id and password are entered. To do this, the logon button is initally disabled. Then connections are made from the entry fields to the button, shown as green arrows in Figure 3. The purple arrows represent connections to fill parameters in the primary (green) connections. The popup menu shown is brought up by right-clicking on a connection. It allows connections to be made for filling parameters and handling exceptions.
Every application will have one or more parameter-from-script or connection-to-script connections. Figure 4 shows the window used to specify which method (script) will be called to fill the desired request.
Figure 4: Parameter-from-script Window.
A minor nuisance is that the window in Figure 4 lists all the methods in the class regardless of whether the method is generated by the programmer or VAJava. This window would be easier to use if it filtered out methods that were generated by VAJava and methods that returned values which did not match the type of the parameter being filled (connected to). Additionally, type conversion is accomplished by calling static methods of certain classes. With the current design, there is no way to directly call these methods, e.g. Integer.toString(int). A sloppy workaround is to declare a method within the object being visually created. This method would call the desired conversion method. This type of method is typically called a "thunk".
Figure 5 shows the Event-to-method properties window. This window allows the programmer to fine tune a connection once it has made.
Figure 5: Event-to-method properties window.
The Bean Editor
VAJava provides a bean editor to quickly browse or create beans. Figure 6 shows the bean editor.
Figure 6: Bean Editor.
The bean editor allows the programmer to create new methods, properties, and events for the bean. Through various "smart guides", complete beaninfo and code is automatically generated to support common operations. For example, Figures 7 and 8 show two pages in the smart guide for creating a new property.
Figure 7: New Bean Property.
The first page allows the programmer to set basic information about the property. If readable or writeable is checked, get and set methods are automatically created. Code to send property change notification as well as to support constrained values is generated if the appropriate check boxes are selected.
Figure 8: New Bean Property.
Additional bean information can be specified on page 2. This information is used to help programmers using the bean within a bean enabled development tool, such as VAJava.
Often to complete a bean, specific methods declared in its superclass must be overloaded. To do this, I prefer to use the Hierarchy view.
The Hierarchy Window
Figure 9 shows the hierarchy window. The lower half of the hierarchy window allows the selected item to be edited. In this figure, the class definition for LED is shown. Methods can be edited by selecting the appropriate entry in the method list. Using this page, methods can quickly be copied to a class from one of its superclasses and reimplemented as needed. For light-weight visual beans like the LED related classes, the paint method must always be overloaded
Figure 9: The Hierarchy Window.
Now that we have seen the features VAJava offers to aid in code creation, we should look at how it helps us get our code working properly.
VAJava includes an integrated debugger. Breakpoints can be set in any VAJava window that allows source code to be edited. When a running application hits a breakpoint, the debugger window shown in Figure 10 appears.
Figure 10: The Debugger Window.
The debugger contains all the features typical to a debugger, the ability to step into a method call, step over a call, execute until the method returns, etc. The call stack and local variables are shown although by default they are proportioned awkwardly. Note that these windows have been resized in Figure 10.
The source to a method can be changed within the debugger. The code is compiled when saved. Then the debugger will execute the modified method from the start. This is a double-edged feature. Sometime re-executing a method can cause resource allocation locks to occur (like attempting to rebind a socket to a port). For the most part though, this feature is very useful.
This concludes our look at the features included in VAJava. To wrap things up, we'll quickly discuss performance and then summarize.
As mentioned before, VAJava is written in SmallTalk. As expected, the environment is not going to set any speed records for Java performance, but then it really doesn't have to. What it does need to be is fast enough so as not to hamper the efficiency of the programmer. With this in mind, VAJava fills this requirement on the tested system. However I would not recommend using anything less than a 133 MHz Pentinum or less than 48 megs of ram. A machine with 64 megs of ram and a Pentinum 166 would likely be the best choice for using the JFC within VAJava.
Importing existing Java code into VAJava is primarily bound by the hard drive. Even with a very fast SCSI hard drive, the CPU was not fully utilized while importing the JFC. The next version of VAJava, due out this summer, will address this issue. Hopefully, the size of the repository and workplace files will be reduced. Note: full support for the JFC will be included in next release.
I used the JGL benchmarks to test the performance of the Java virtual machine. When running under VAJava, the benchmarks took significantly longer to run than they did under version 1.1.5 of Sun's JDK. Therefore, I would not recommend VAJava for testing applications which are primarily computational.
VAJava requires a fair bit of computing power but it makes designing GUI applications easy. There was a time when developing the user interface was the least enjoyable part of application development. VAJava makes designing the interface quick, easy and as enjoyable as it can be.
The incremental on-the-fly compiler allows code changes to be tested even when the application is running. This is a great productivity booster when fine tuning code.
If you have a computer with enough power, VAJava is great for the beginner or veteran programmer. For more information, or to download an introductory version of VAJava see the VAJava home page at .