In June 1995, when I first heard that Borland was going to make a Java tool, I was quite pleased. Borland was the only company that put a dent in the Visual Basic franchise that Microsoft had created. Further, Borland's Delphi development environment is considered by many (including myself) to be the best rapid application development (RAD) tool on the market. So it was with great excitement that I bought Borland C++ 5.0 with Java support late in '95.
Unfortunately, the Borland effort left a lot to be desired. One of the product's biggest drawbacks was that the Java support was an add-on module to C++, rather than being a tool in its own right. The problem with this approach is that Java wasn't all that much like C++ in terms of its compilation units, object files, and compilation targets. In Java you compile a class file into an object that you can immediately instantiate with other objects that are already on the system. There are no ".exe" and ".dll" targets, which are the model used by the generic C++ IDE. Thus, building classes was cumbersome, the documentation was nearly non-existent, and the experience was wholly unsatisfactory. The C++ compiler worked great though.
On the heels of the C++ add-on product, word quickly got out about "Latte," the code name for an IDE environment that the engineers from the Delphi group were going to work on and that was written completely in Java. The ambitious project was beset by delays; it demoed at the first JavaOne Developer Conference in San Francisco in 1996 and then again at JavaOne '97. Finally, it has been released as JBuilder.
A quick tour of JBuilder
JBuilder shares many common themes with the Delphi world and feels similar enough to the Symantec Visual Cafe tools. So it was easy for me to get going with JBuilder -- even without reading the supplied documentation. (When I did have a question, the documentation was fairly complete in terms of describing the available options.)
The environment consists of a "control bar," which is a floating toolbar window, a "browsing window" with a layered tree control on the left, and a viewing window on the right. There is only one control bar, but several browser windows can be open.
The control bar, shown below, consists of the standard menu commands across the top, a palette of tools on the left that provide shortcuts to the menu items, and a collection of components (JavaBeans) that are available for use in your visual application or applet. Below the tool palette and components is a status line that is updated with whatever activity is taking place at the current time.
The browser window is shown below. This window is where you interact with your source code, either HTML or Java. Above this is the control bar, which lets you start actions (such as a rebuild) and holds your collections of JavaBeans for use in your own applications. Further, each browser window can display a project going on in it, so if you are working on multiple projects -- such as a new JavaBean and an application that uses it -- you can have both projects open at once and easily move between them. This capability impressed me as it supports the most common form Java development, changing several different pieces at once. In one browser window there can be a project of utility classes, in another browser the applet that uses those classes, and in a third a set of HTML pages that use the applet.
The browser window is split vertically -- with the file tree view on the left and the viewer on the right. The vertical split is called the "curtain." Borland's user interface allows you to remove the curtain when you want a full-screen view of the source code you are working on. Under each half of the browser window are control tabs that change the semantics of the view itself.
When viewing Java source code, the tabs on the viewer-half of the browser are labeled source, design, and doc.
The source tab simply shows you the source code, and you can edit it using the included syntax highlighting editor.
The design tab shows a visual workspace where any user interface information you've defined exists. So, for example, if your source code had panel definitions, buttons, and so on, this panel is the drag-and-drop area where you can compose that information.
- The doc tab shows you the HTML document that is generated from the nested comments in the source code. The HTML document can be extracted using JavaDoc, however, there is no automated way that I could find to generate this document.
Perhaps one of the most clever aspects of the browser implementation is that when you browse a class file, the browser reads in the class file and decompiles it enough to show you the structure of the source code. This can be very helpful if you are used to reading source, rather than looking at an object diagram. Further, when you select any of the Java standard classes or the Borland custom classes, clicking on the doc tab will return the JavaDoc page for that class. This allows you to do things like: highlight a system class, select "browse selected symbol", and see both the reconstructed source, or the documentation for the class. I prefer this method, which preserves the HTML formatting that is embedded in the JavaDoc data, to systems that convert the Java documentation into Microsoft "help" files.
The JBuilder debugger
Of course, writing code is easy. It's getting it to work that's hard. Perhaps the most important feature for any IDE is its debugger. Fortunately, the Borland JBuilder debugger does not disappoint. A screen shot of the debugger is shown below.
When debugging, the browser window is reconfigured to support looking at your class's status. The tree structured file view is split into an upper window containing thread status and a lower window containing information about active variables. Also, the left half of the browser gains some addtional tab controls at the bottom that control the operation of the debugger.
Additionally, pop-up windows will display a variable's value in the source window in much the same way that Symantec's debugger works. All of the standard debugging features are present: single step, watch points, break points, conditional break points, and so on. Of note is the thread support, which is outstanding. In the thread window in the upper-left corner, you can click on the currently-executing line of any piece of code in any thread, and the source window will pop to that place in the code. Furthermore, the lower-left window will display any local and global state that is visible to that thread. JBuilder's debugger definitely represents the new standard against which other Java debuggers will be measured.
Along the left side of the source window, small dots indicate lines where breakpoints can be installed. Clicking on the dot highlights the line, and the breakpoint symbol appears. Another useful feature is "run to cursor" -- for those times when you don't want to single step through every iteration of a for loop. Simply click on the line, select "run to cursor," and execution stops right there.
Handling output
A final area in which I found JBuilder to be particularly useful was its handling of the output from executing a Java application. The execution log is a window that contains all of the data sent to System.out from the current run. However, when multiple projects are open, the execution log maintains separate tabs for each project! An example of this is shown below.
As you can see in the image there are two tabs, one for "example" and one for "BASIC," the current project. This separation is essential when building multiple class libraries at the same time because it keeps you from mixing up the output from the two projects.
What I like about JBuilder
Sometimes it is the little things. I really like that one can print Java source code to a color printer and have it come out with its fonts and syntax highlighting intact. If I could customize the page headers and footers and specify a "two-up" output (two pages of source code printed side by side on a landscape output page), it would be perfect.
The support for Java 1.1 is very nice. While JDK 1.1 has been out for a while, and Symantec has had beta support for 1.1, there is nothing like having an IDE that is designed from the ground up to work with 1.1.
As I stated earlier, the debugger is very nice as well: It gives a large amount of information in an easy-to-comprehend way. Much of the debugging is "point-and-shoot" style, which some users like (I do) and some don't (believing that "gdb" stands for God's DeBugger). I believe it's sufficient to find even the most difficult thread deadlock bugs.
What I dislike about JBuilder
JBuilder's configurable IDE actually isn't configurable in two crucial ways:
First, you can't set the default background and foreground colors in the display. Instead, you first have to set them for your entire desktop and then JBuilder will notice the changes. You can, however, set them using some of their "canned" color schemes.
- The second serious defect is that you can't customize the editor's keystrokes. My two favorite editors in this regard are EMACS and the Programmer's File Editor (PFE). JBuilder's editor customization tab consists of being able to select some prepackaged key mappings -- default, Brief, Classic, and Epsilon are included -- and being able to select how things such as auto-indenting, highlighting, and wrap-around work. I'm still looking for the editor that lets you define macro packages in Java.
In the area of presentation, JBuilder suffers from some simple bugs that I expect will be fixed in the first patch release or so. For example, if your desktop has "Large Fonts" selected (which Microsoft insists means to take Arial 10 and "multiply" it by some factor), the computation on how much space is needed by the toolbar breaks and the component libraries icons are cut off. If, on the other hand, you set the font appearances explicitly in the "Appearance" section of your desktop properties, such as 14 point Arial, then the component bar is rendered correctly. Clearly, it's a Microsoft bogosity (where a 10pt font doesn't always render as a 10pt font), but the folks at Borland need to deal with it.
Another area that I dislike about all IDEs for Java is the reliance on their own "custom" Java virtual machine for development. I hope that in the future, the IDEs will be usable with the standard Java Runtime Environment (JRE) and a few custom libraries. No one has done this one right yet.
What I wish it had
Of course, no product is a perfect fit for everybody, so what I'd like to see may be considered noise to other folks. But, in the spirit of speaking out, these are the top three things I would like to see in JBuilder (or any solid IDE for that matter):
Finer IDE configuration control -- key mappings, display colors, and layout
Profiling support in the debugger -- call tracing/timing, heap usage, garbage maps, and so on
- Source code control -- this is an area where Java is weak (version control), and a smart control system that noted when the contract changed (incompatible class changes) and what changed when, would be a real treat
Wrapping up
The JBuilder tool is a very capable entry into the increasingly crowded IDE market place. It delivers extraordinary capability in some places -- such as JavaBeans, debugging, multiple projects, and user interface design. This release of JBuilder has some rough edges around the presentation and configurability of the IDE, however, this is to be expected in a 1.0 release. Its support of Java 1.1 is superior as well. My take is that, for the first time, the guys and gals at Symantec have some serious competition to their Visual Cafe Pro product.
This story, "A first look at Borland's JBuilder IDE" was originally published by JavaWorld.