NOTE: Borland has now released JBuilder 3, a signficantly updated new version of JBuilder. In an upcoming issue, we'll be replacing this article with a new article on JBuilder 3.

Not too long ago, when its name was still Borland, the Scotts Valley, CA., company now known as Inprise set new standards in application generators when it released of a Pascal-based development package named Delphi.

Delphi is still a top seller in the shrink-wrapped IDE market (Delphi 4 had just been released when this article was written).

And an even newer product -- one that looks and feels a lot like Delphi but is designed for creating programs in the Java^TM programming language -- now shows promise of coming on even stronger.

Its name is JBuilder 2, and it's one of the first Java-based IDEs to have Swing capability built in.

JBuilder 2 is a feature-packed GUI-style integrated IDE that has lots of parts and does lots of things. Like all the integrated IDEs reported on in this issue of The Swing Connection, JBuilder 2 provides all the basic ingredients that one ordinarily needs to create, design, debug, and execute in the Java^TM applets and application-- an editor, a select-and-drop component and user-interface designer, and a viewer tool for previewing applets and applications.

JBuilder 2 is available in three versions -- JBuilder 2 Client/Server Suite, JBuilder 2 Professional, and JBuilder 2 Standard. Two important features included in all three versions of JBuilder are:

• JDK switching, a feature that allows developers to compile and run their applications against any Java Development Kit virtual machine (VM)-- from JDK 1.02 through JDK 1.2, and beyond.
   
• JFC/Swing component integration, which can create 100% Pure Java^TM user interfaces using Swing. In addition, JBuilder 2 includes a set of proprietary extensions to Swing components that are designed to interface with relational databases. Borland says its data-aware Swing extensions are fully JDBC-compatible, yet also make use of Inprise's DataExpress architecture.

To construct a program using JBuilder 2, you use techniques that are familiar to the users of most other full-featured application builders. To design your program's graphical user interface, you open a design form. Then you drop components onto it by selecting them from a component palette. As you place components on your design form and move them around, JBuilder automatically generates whatever Java code is necessary to create a working copy of your design form in a working applet or application at runtime.

To equip your applet or application with its own unique functionality, you use JBuilder's built-in source-code editor to insert your own code into the code that JBuilder generates. When you're done, you have a full-fledged application written in the Java programming language -- and, if you wish, with Swing support built in.

The following illustration shows JBuilder's design form, along with a property sheet, a file browser, and a project browser.

JBuilder's component palette is divided into several tabbed sections -- and three of them show right away that JBuilder's creators are committed to Swing. One of the tabbed sections, labeled "Swing," displays a page of icons that represent Swing components. Another tabbed page, labeled "Swing Containers," contains icons representing Swing containers.

There is also a third Swing-based component set labeled "dbSwing." It contains a set of icons representing a collection data-aware Swing component extensions created by Inprise. JBuilder's library of dbSwing components -- implemented as JavaBeans -- include objects such as text fields and lists. Every dbSwing component is an extension of a corresponding Swing component. But each dbSwing component has been made data-aware with the addition of some extra properties, such as dataSet and columnName. This arrangement "dramatically increases programmer productivity when creating applications using data, as most business applications do," an Inprise spokesman said.

There are also two tabbed pages on the component palette labeled "JBCL" and "JBCL Container." "JBCL" stands for "JavaBeans Component Library," the name of a component library created by Inprise and shipped with JBuilder 2. Most of JBuilder's JBCL controls are derived from Swing components.

Other features of JBuilder that support Swing include:

• Code Insight: A set of high-productivity coding wizards that assist developers while they are programming, allowing them to build more robust applications more quickly. CodeInsight highlights invalid data types and provides you with the proper syntax when you are creating and editing parameters, properties, methods, and events. As Code Insight works off of the source code, it fully supports the Swing components.
   
• Two-Way-Tools: A unique feature of JBuilder is a set of "Pure Java^TM Two-Way-Tools" -- a set of visual designers that generate 100% Pure Java applications without proprietary markers or binary files. This design gives developers the flexibility to work in JBuilder's visual designer when that is appropriate, and in the IDE's source-code editor (using Code Insight) when that is appropriate. This arrangement gives developers the freedom to switch back and forth as they please.
   
•  A BeanInsight tool for analyzing JavaBeans^TM. BeanInsight can be a useful tool for learning information about components, including inheritance tree and exposed properties.
   

There are several other features that enhance JBuilder's compatibility with Swing:

• Swing components and Swing containers are integrated into the environment, and are pre-installed in the Swing and Swing Containers tabs in the JBuilder component palette.
   
• The creators of JBuilder have customized some of JBuilder's features to support specific Swing component features; for example, as addTab() method to support Swing's  JTabbedPane component.
   
• JBuilder provides a set of BeanDesigners that work in conjunction with BeansExpress to create custom components that are easy to reuse. These components, based on existing Swing components, are designed to let corporations create custom business components that are based on Swing.
   
• JBuilder's wizards automatically generate source code using Swing components. JBuilder wizards that generate Swing code include:
   
• The Application wizard, which sets your Swing program's look and feel.
   
• The Applet, BeansExpress (JavaBean), Frame, Dialog, and Panel Wizards.

Several other JBuilder wizards, including the Implement Interface and Override Method wizards, also support Swing components.

To evaluate JBuilder's Swing support, we decided to create a small applet modeled after the "Swinging Duke" applet, which is introduced in the article in this issue titled "Make Your Browser Swing!":

Our goal was to create an applet that would look and behave as much like our original Swinging-Duke applet as possible. When you run the original SwingingApplet program, you see a small panel that contains a picture of Duke (the Java^TM mascot) sitting in a swing. Below Duke's swinging figure, there's a toggle button that says, "Swing!" Click the button, and Duke starts swinging. Click it again, and he stops. This is the behavior that we sought to emulate.

When we began the process of creating an applet using JBuilder -- by choosing the File|New|Applet item from the JBuilder menu -- we immediately saw that the creators of JBuilder had been working on Swing support. When you issue the File|New|Applet command, JBuilder displays an applet wizard that offers you the option of using "only core JDK and Swing classes" to create the applet you're about to design.

Once you have informed JBuilder of your intention to create a Swing applet, JBuilder automatically derives your applet from Swing's JApplet class instead of from the old AWT Applet class. Unfortunately, from that point on, the current version of JBuilder 2 doesn't necessarily support everything you might want to do. Because of complexities in the way in which Swing container classes work -- complexities that old-style AWT components did not have -- the current version of JBuilder 2 doesn't quite understand how to deal with Window-derived Swing classes such as JApplet, JPanel, JFrame, and JDialog. (For more details that might help explain why, see the article titled "Understanding Containers" in this issue.)

For example, when we placed a second container -- specifically, a JPanel object -- inside a JApplet object, the outline of the JPanel object disappeared into the background, and then we couldn't see where we had placed it.

After some experimentation, we stumbled upon a partial solution to this problem. We  used JBuilder's property page to change the background of the offending JPanel to a contrasting color -- namely, purple -- and then the JPanel object that we had placed inside our JApplet object looked like this:

Now our JPanel was visible. But then we discovered that JBuilder's component palette was not equipped with an icon representing Swing's ImageIcon class, which is relatively new to Swing and is currently represented on very few IDE component palettes. (You can add icons to the JBuilder component palette whenever you like, and you can update JBuilder to support the latest version of Swing at any time you like, but we chose not to do either of those things for this one test.) Anyway, we found that we could display Duke's picture inside our JBuilder applet quite easily by ignoring Swing's ImageIcon class and substituting a different component -- specifically, JBuilder's JBCL Image Control component -- for the ImageIcon component that was used in our original Swinging-Duke program. When we did that, we didn't need an ImageIcon object.

Next, we discovered that the JBuilder 2 component palette doesn't yet provide an icon for a JToggleButton object. (The JToggleButton class wasn't available in AWT, and three of the four IDEs we evaluated in this section offered no component-palette support for JToggleButton objects. Again, we could have updated our copy of JBuilder to include support for JToggleButton, but we decided that for this test, that would have also been more trouble than it was worth. Instead, we decided to equip our JBuilder applet with two regular JButton objects, which we simply plucked from JBuilder's Swing component .

When we tried to use the BorderLayout manager to arrange the components inside our applet, we discovered some odd behavior: Each time we placed a new component inside our applet, that action changed the positions assigned to all of the JApplet's children. We suspect that this behavior was related to certain anomalies that Swing manifests when it tries to lay our left-aligned, center-aligned, and right-aligned components. (For details, see the Box layout information presented in The Java Tutorial.) Anyway, this behavior didn't prevent us from going ahead and completing the Swing applet we were building with JBuilder.

In the end, we completed our JBuilder applet by simply using JBuilder's source editor to write all the code for which we could find no component-palette icons or other visible means of support.

On the plus side, it wasn't at all difficult to incorporate code we had written ourselves into code generated by JBuilder. Much of the work involved in designing a good IDE involves a tradeoff between how much work should be done by the IDE and how much work should be passed on to the IDE's user. Some IDEs are so automated that they can generate almost all the code required by a simple application. Other IDEs do less work, and require the user to do more.

JBuilder's tradeoff between automation and hand-coding might not be perfect, but it's close. In fact, of the four IDEs we tested for this Special Report, we found that JBuilder 2 was the one that makes it easiest to add handwritten code to automatically generated code sequences.

We would have liked JBuilder even better if its support for Swing had been implemented a little more smoothly -- but that's a flaw that every IDE is going to have until it has been synched up with the newest version of Swing. Once all of JBuilder's Swing-related kinks are worked out, it may be just the IDE you're looking for.

When we informed Inprise spokesperson Klaus Krull of the experiences we had encountered in using JBuilder, he said: "Going forward, we are committed to improving our support for Swing components within the JBuilder environment, and we look forward to working with the Swing team to provide ease of use to go along with the existing power power of Swing components."

Krull said that Inprise would make sure that all the bugs we had encountered are worked out before the next rev of JBuilder ships. He also said that Inprise expects Swing to be much easier to use in the next version of JBuilder.

In addition, he pointed out that although the current release of JBuilder is designed to support Swing 1.0.1, "you can use use Swing 1.0.2 (or a later version) by shutting down the JBuilder IDE and replacing the swingall.jar file in the \jbuilder2\lib directory with the updated version just (making sure to back up your existing swingall.lib file.)"

Krull also mentioned some caveats. "There is a bug in Swing 1.0.2," said -- "when drawing certain components using the Java look and feel, and when dealing with images in certain cases, you may notice that the existing swingall.jar in the \lib directory is larger than the swingall.jar provided by Sun." He said that's because "we include dependency files within this copy of swingall.jar to increase the compilation speed."

To learn more about JBuilder 2, follow this link to the Inprise Web site.

--Mark Andrews

____

Swing team member Eric Armstrong contributed to this report.