Building platform-neutral Java: Which tool is best?

We compare Java Workshop 2.0, JBuilder 1.0, Visual Age for Java 1.0, and Visual Cafe for Java

Index

Introduction

Platform neutrality is the raison d' etre of Java, which is what makes it perfect for network-centric computing. If you are developing Java applications in anticipation of having your programs run on everything from Network Computers to Unix workstations, you should work as if the lord of platform neutrality hovered over your shoulder like a micro-managing boss.

Unfortunately, you're likely using Windows as your development platform. And many Windows-based development tools hinder rather than help developers create platform-neutral applications.

No, this is not the result of a covert plot by Microsoft to co-opt Java. It is more likely that when vendors designed their Java development tools, some of them may have underestimated the importance of Java's platform-neutral features.

So which tool is the best one to use to create platform-neutral applications? When it comes to Java byte-code compatibility across Java virtual machines (JVMs), it is difficult to say -- the Java Development Kit (JDK) is still a rapidly moving target. But it is not so difficult to determine which tools best exploit the platform-neutral features of Java, particularly when it comes to visual development.

And that leads us to our comparison of four powerful Java development tools. We examined the following products to find out how well they lend themselves to visual development of platform-neutral applications: Sun Java Workshop 2.0, Borland JBuilder Professional 1.0, IBM Visual Age for Java 1.0 Enterprise Edition, and Symantec Visual Cafe for Java Database Development Edition 2.0. We also evaluated the visual programming features of each product, and the breadth of the default palette of visual components.

How they rank -- an overview

We graded the products from A to F in the following categories:

  • Ease of creating a form based on the gridbag. (We also list the time it took to create a test form.)
  • Maintainability of the form.
  • Visual programming capabilities.
  • Breadth of default component palette.

Java Workshop 2.0 is the hands-down winner when it comes to giving you the visual tools necessary to create an attractive, platform-neutral user interface based on a gridbag layout. This is because Java Workshop is the only tool that builds its visual designer around the gridbag layout. This makes Java Workshop 2.0 somewhat inflexible at times, but as an all-purpose tool, it can't be beat.

If you want both ease and flexibility of visual layout, JBuilder is the best choice. JBuilder lets you design a layout using absolute coordinates and then convert it to a gridbag without many consequences. It then makes the management of that gridbag layout fairly easy.

Visual Age for Java and Visual Cafe for Java are the goats when it comes to visual layout. If you want to use a gridbag layout with these products, it's all done with trial-and-error setting of gridbag constraint variables.

Visual Age for Java is light years beyond the other products when it comes to visual programming. There's almost nothing you can't do with a mouse and the Visual Age Visual Composition Editor. But it's a bear to learn. Visual Cafe for Java, on the other hand, will do most of what Visual Age offers in the way of visual programming and make it much easier to get there.

Java Workshop doesn't go nearly as far as Visual Cafe when it comes to visual programming. There are some neat tricks you can do, but you're still better off writing your code by hand. Don't bother trying to do any visual programming at all with JBuilder. Borland should have left out its lame visual programming wizard until it could have provided something more than the embarrassment that ships with the product.

Without creating a massive application, it would be hard to pick a winner between JBuilder and Visual Cafe for Java when it comes to the breadth of the default component palettes they provide. We especially appreciate things like the timer control (for triggering events) on the Visual Cafe palette. JBuilder includes some nice chart controls, too. Visual Age is leaner, but includes a broad range of useful Java classes. Java Workshop is the stingiest of the products when it comes to palettes.

We don't enumerate every control these products offer (you can expand the palettes as you wish, anyway), but we do include some images of the default palettes so you can get an idea of how many controls are available.

Rationale and methodology

Aside from idiosyncrasies of JVMs, the problems of platform neutrality most often surface in a tool's approach to visual Java GUI design. Windows-based tools tend to perpetuate the What You See Is What You Get (WYSIWYG) approach to visual development. With WYSIWYG design, you drop a button at a particular location on a form and that's exactly where you can expect the button to appear when you run the application.

It is a familiar environment for Windows developers. But this approach will almost always generate applications that have display problems on platforms other than the one on which the application was developed. That unplanned-for platform may display the button with a different degree of 3D shading -- shading that obscures the button's label text -- or it may automatically enlarge the button to display the text, causing the button to overlap an adjacent visual control.

It's in the gridbag

Java provides something called the

layout manager

to address exactly this problem. A layout manager resizes and rearranges visual controls to adapt an application's user interface to the current platform.

Java includes a number of default layout managers, including the card layout, grid layout, border layout, flow layout, and gridbag layout. Each one of these layouts can be useful at one time or another, depending on the type of interface you're trying to design. Of these layouts, card, flow, and border are probably the easiest to use; however, the grid layout is also fairly simple. You can also set the layout to NULL, which defaults back to a WYSIWYG coordinate-based design. Or if you wish, you can program your own layout managers.

Of the layout managers that ship with Java, the gridbag layout tends to get the most use because it is the most flexible; however, many programmers find it the most difficult to master. The gridbag layout consists of a grid of cells, but the arrangement of components within those cells doesn't have to conform to a rigid X,Y coordinate system.

The empty gridbag with 12 cells.

You can drop a component into a single cell or have a component span several cells.

The button is in the upper-left cell, but the

You then weight components within a gridbag layout to control where the visual components will tend to align themselves, or to determine their behavior when the user expands or contracts the window. You can weight components so that they will be more likely to remain in their current position when their surroundings change.

The weights can also determine whether your components take up more or less horizontal or vertical space when the window is adjusted. This technique is useful when you want a list box or spreadsheet component to expand to take up all available space, but you want your buttons to remain basically the same size.

These settings are called gridbag constraints. Each component that is placed within a gridbag gets its own set of gridbag constraints, which determine that component's behavior in the layout.

The neutral zone

As difficult as it is to master, the gridbag layout is the best layout "out of the box" for designing application screens that are both platform neutral and attractive. So we chose the gridbag as our baseline for our tests. We designed various forms in each product using the gridbag layout, and rearranged these forms, switching between layout types in order to exercise how well each product allows the developer to maintain and modify existing designs.

We created a moderately complex form (twelve components of various types) and tweaked the gridbag settings until the form took on the desired appearance. The form had to remain attractive when resized or run under a different platform (we used both Windows NT and Linux).

Once you finished a form, you have a pretty good feel for the gridbag constraint settings necessary to make the next form take on the desired appearance. This seeming benefit actually presents a trap for testing purposes; what we learned about the gridbag settings from one product would make the next product seem easier to use.

To combat this dilemma, we arranged and rearranged the components differently each time, and then cycled back through the products twice to give each one three chances. Once we were comfortable with the product, we recorded the time it took to create a visually appealing form (as opposed to a usable, but un-tuned layout of components). We then evaluated the difficulty in revising that form.

There is more to a visual designer, however, than the arranging of components. Some products allow you to program the behavior of your application visually. We tested this capability for each of the products, as well. Finally, developers are always keen to have a variety of components from which to choose. So we rated each product according to the depth of its default set of visual components. Fortunately, most tools make it possible to add to the component palette, so a weak palette isn't usually a deal-breaker for Java development environments.

It is important to note that we compared these tools primarily from the perspective of visual applications design. In so doing, we compared only a narrow portion of each product's strengths and weaknesses. Consequently, we give no bottom-line score for these products. Please see our Feature chart for more details about those features not tested in this comparison.

Java Workshop 2.0

Report card

Ease of

form creation:

A+

Time to

complete form:

3 min.

Maintainability

of form:

B

Visual

programming:

D

Breadth of

default palette:

C

Ease of form creation

Java Workshop is a unique blend of brilliance and folly. When it comes to ease of creating a platform-neutral gridbag layout, Java Workshop 2.0 fulfills the mission far better than any competing Java development environment. But its finesse is often offset by awkward and annoying, if harmless, design decisions.

The gridbag layout-based visual designer takes some getting used to, but it is well worth the effort. The difficulty in learning this tool isn't as much the fault of Java Workshop as it is a consequence of moving from a traditional WYSIWYG design environment to one where platform neutrality reigns supreme.

Once you've mastered the approach, however, design is a breeze. You can drop components and size them across grid cells very easily. You manipulate gridbag constraints settings (such as weights and fill-factors) by clicking on sections outside the grid. If at any time you want to check how the form will look during runtime, you can make an instantaneous switch to preview mode. You can then resize and manipulate the preview form to see how your design reacts to such changes.

Sun Java Workshop 2.0.

There are a few minor goofs in the design. For example, you have to pull down a combo box to switch between design and preview mode when laying out a form. This requires two clicks for a one-click operation. The one-click alternatives (a button, a checkbox, two radio buttons, a custom on/off switch) outnumber this approach by such a wide margin, you get the impression Sun had to go out of its way to be annoying.

Even something as simple as moving a component from one spot to another proved more difficult that necessary. You have to click and drag from a very specific spot in a cell, and that spot isn't always directly on the component itself.

You aren't restricted to using a gridbag layout for every piece of your application, but every visual object in Java Workshop ends up within a gridbag layout sooner or later.

For example, you can create a flow layout panel. But you can't populate it directly by dropping components on it from the palette. You must open up a settings dialog for that flow layout panel, and then insert a number of items. These items are -- you guessed it -- gridbag layout panels. You then populate each gridbag layout panel with one or more components.

In the end, you get a panel that appears to be populated only with components, but each component has its own gridbag. We could find nothing problematic in this approach (in fact, it's possible thi approach will speed up development), but the idea took some getting used to.

Maintainability of form

Although you can add a single row or column to the working grid, you can't delete just a single row or column. When you click on the grid, the intersection between row and column, including both the row and the column, are selected, so when you press the delete key, you delete both.

When you select anywhere in a Java Workshop

If you ever find yourself in a position where you must delete just a single row, you must add a column, select the intersection between the row targeted for destruction and the new column, and then delete both. While this approach isn't particularly difficult, it will go down in history as one of those stupid interface tricks that should never have been necessary.

1 2 3 Page 1
Page 1 of 3