Title: JBuilder 3

This review was written in July 1999 and first appeared in the August issue of EXE. Since that time Borland have released the non-Windows variants referred to.

During the early '90s I upgraded my home computer on a regular basis (around 18 to 24 months) to keep pace with the increasing demands of the development tools I was using. Something strange happened in the latter half of the decade - I started using Java (instead of C++) for my recreational programming and the demands actually declined. For a variety of reasons development using Java technology is less resource intensive than using C++.

A change in my approach to development tools has also effected this reduction in demand - rather than using an IDE to supply all my needs I've been supplementing the JDK with purpose built tools like a "programmer's editor" (CodeWright) and the "jikes" Java compiler from IBM's "alphaworks" web site (http://www.alphaworks.ibm.com/). This approach also works for C++ - I recently removed MSVC++ 4 and replaced it with the Cygwin development tools and gained over 150Mb of disk space in the process. As a consequence of this my current home computer has survived without a hardware upgrade for over three years!

Sadly this system (P125/32Mb) is now totally inadequate to support JBuilder "enterprise". JBuilder is big - not so much in terms of the disk space it requires (only 215Mb for a full installation) but in terms of the amount of RAM required to start it up. According to the "README" the minimum requirement is 128Mb RAM (and a P166), I tried it on such a machine, but while it does run in this amount of memory, but when working through the "hello world" tutorial and switching between the IDE and the help system there were poor response times and noticeable disk activity. (I took a peek at the system memory - this was fluctuating between 150 and 170Mb.) On this basis (and since I usually have a few other applications running) I'd want to equip a development machine with around 192Mb for serious use.

Having said all that, I borrowed a P133 with 96Mb of RAM for the review period and, so long as I stayed within the IDE and avoided the help system it was perfectly responsive. According to the Borland website, the "professional" and "standard" variants require less RAM. This may be true: I've not seen them. However, I was working through a very simple example and wasn't using any "enterprise" specific features.

In the past I've used Visual Cafe, Java Workshop, and VisualAge Java. These are all popular products and the only one of these that came close to JBuilder's memory requirements is VisualAge. Compared to the £1500 price of JBuilder "Enterprise" RAM is cheap, but many other things can make it an issue - corporate bureaucracy is one. I spent a good deal of time a couple of years ago making the case that the then "standard configuration" for developers had an inadequate amount of RAM. That fight is now won for me, but in other organisations it may not yet have been addressed.

The development of the Java platform is tightly coupled with the "Java Development Kit" [JDK] implementations that Sun develops. The reason is simple - Sun both controls the Java standard and provides a free, de-facto reference implementation of it. Currently Sun's JDK is at version 1.2.1 (the first "bug fix" release of 1.2). "Java2" is the version of the Java platform implemented in JDK1.2.x. According to an advertisement I have in front of me "JBuilder delivers Java 2.0 support first". (I think this claim to being "first" is a trifle exaggerated, but no doubt Borland would argue that the existing suppliers of Java2 support are not competing in the same race.)

Sometimes I feel like King Canute - there are serious problems in the GUI event handling in JDK1.2, JDK1.2.1 and in the first candidate release of JDK.1.2.2. These have discouraged me using Java2 for GUI code (I do use it for servlets). Meanwhile the Java2 wave washes past me while I say (for instance) "stop! <Alt>-key mnemonics do not work as advertised". While I know there are workarounds for many of these problems I wish that instead of an ever expanding range of APIs Sun would concentrate on getting their implementation working.

Anyway, as a result of these problems, there are a number of characteristic problems in GUI based Java applications running under JDK1.2 on Windows. The JBuilder IDE is clearly a Java2 application running the Swing "Windows look and feel" since it suffers from a number these problems. (For instance: the first dialog in creating a new project allows you to tab into a "comments" field - subsequently to get out of that field or to select an action button it is necessary to use the mouse.)

Borland has attempted to deal with some of these problems. For instance, to avoid the problem with <Alt>-key mnemonics mentioned above there are no keyboard mnemonics for action buttons on any of the dialogs. I find this a source of constant irritation since I need to tab to the appropriate action button (or, in some cases, reach across the desk to use the mouse). Obviously there are marketing advantages to shipping under the Java2 logo and Borland is committed to removing the last few traces of Delphi code from JBuilder and launching a "pure Java" version on Solaris and Linux later this year (there should also be a "pure Java" update to the Windows version).

On the other hand, being a Java application is no excuse for a sloppy user interface; JBuilder is competing on Windows and should conform to the spirit, if not the letter, of the "Windows Application Programming Guidelines". Instead of this attempt to ride the Java2 wave, I'd prefer a keyboard friendly IDE with action button mnemonics (even if it were based on JDK 1.1) that allowed me to select Java2 as the development platform.

Sun has shipped JDK1.2 on its version of UNIX and for Windows but is still actively supporting JDK1.1 - both 1.1.7b and 1.1.8 shipped after Java2 was launched. On most other platforms JDK1.2 is yet to ship. For example; IBM provides JDK1.1.7b on most - if not all - of its platforms (and also for Windows) and JDK1.1.6 for Linux, Apple supplies JDK1.1.7 for the Mac and Symbian supplies JDK1.1.4 for EPOC (Psions and mobile phones). It is a heterogeneous Java world and developers will need to support a range of Java versions.

JBuilder comes with JDK1.2 but it is designed to support development for a range of different JDK versions. I currently make more use of JDK1.1 than the JDK1.2 that ships with JBuilder. So one of the first things I did was to switch to IBM's Windows JDK1.1.7b with Swing-1.1.1-beta1 (I happened to have these installed on the PC I used for JBuilder). This was wonderfully uneventful: it was obvious how to do this; it worked first time, I didn't encounter any problems.

For any version of Java and/or associated packages you can define a "JDK" within JBuilder - supply a JDK, specify the search paths and it is done. Having defined a JDK JBuilder remembers the paths associated with it. It also allows you to specify the default JDK for new projects, set different JDKs for different projects or to change the JDK being used for a particular project.

Borland missed an opportunity here - the name is taken from the JDK and duplicate names are not allowed (I'd like to set up one "JDK" to be "IBM's JDK1.1.7b with Swing-1.1" and another to be "IBM's JDK1.1.7b with Swing-1.1.1-beta1"). Admittedly it is possible to select the libraries for each project, but the ability to define standard configurations and switch between them would be nice. The need to support a range of development and/or deployment environments isn't likely to change in the near future. JBuilder provides support for this that is a lot more maintainable than the batch files I've got set up currently to manage a range of Java environments.

The exact complement of features varies according to the variant of JBuilder ("standard", "professional" and "enterprise"). As I've only seen the top-of-range "enterprise" variant I don't have detailed knowledge of the other variants - I trust that they are similar, with some features unavailable. Where Borland's documentation or advertising identifies which variants contain a feature I'll mention it, otherwise caveat emptor.

As one would expect from an IDE there is an integrated source browser/editor, GUI design tool, bean design tool, a debugger, and a conjuration of wizards. I'll cover each of these in more detail below. But first a quick tour of features that are worth a quick mention, but that I don't have space or time to cover in detail.

ObjectSpace's excellent "JGL" container & algorithm library is also included. Although this is also available free on the Internet (http://www.objectspace.com/) its inclusion is useful as it contains powerful tools that reduce the need to reinvent wheels. Sadly, Sun appear to have suffered an attack of "not invented here" and produced their own containers package in Java2 instead of adopting the JGL library into the standard. I fear that JGL, despite its merits, will be swept aside by the marketing force of "free AND from Sun". Borland has developed a collection of complementary packages that extend the support for database access and display beyond that provided by the standard JDBC and Swing libraries. The level of support varies between the "enterprise", "professional" and "standard" variants: at the higher levels it contains classes such as "data aware" extensions to Swing and data access components which provide the support these require.

In the "professional" and "enterprise" variants are the InfoBase database server and a "companion tools" CD of third party software, this is a compendium of "lite" versions, trial versions, and freely licensed software - do read the license conditions of any you choose to use. (If your "companion tools" CD has a root directory overwritten with the installation directories of all of these products and consequently doesn't work - don't worry; Borland have identified the problem and are shipping replacement CDs on receipt of registration details.)

The PVCS version control system is integrated into JBuilder "enterprise", PVCS is a workmanlike product that has an established reputation - it does the job. If you are looking for "everything in one box" then this will probably meet your version control needs. For me (and many others) its inclusion is an irrelevance: the whole point of version control software is that it is boringly reliable and stable over time. I already use Visual SourceSafe at work and RCS at home and am not going to switch.

Also in the "enterprise" variant is a Pure Java database engine "DataStore". This may be embedded directly into an application either to remove dependencies on an external database engine or to cache result sets. This all goes beyond the fairly basic data access requirements of the type of application I deal with in Java, so I'm not qualified to comment on the usefulness of these components in a production environment.

Something I intend to experiment with is the VISIBroker "Object Request Broker for Java" 3.3 (only in JBuilder "enterprise"). The "enterprise" box also contained C++ Builder version 3 (Version 4 is current) but this isn't mentioned in any JBuilder documentation that I've found.

There are quite a lot of things about JBuilder 3 that I like, there are also quite a few that I dislike. Many of the things I dislike also apply to the competition - for example I've never used an IDE in which I've liked the editor. (Programmers seem to divide into two camps, those that use whatever is in the IDE, and those that use a more powerful external editor such as EMACS, CodeWright or SlickEdit - you will know your own preferences).

Also, I tend not to develop much code for the areas covered by the code generation wizards - and when I do I want it to fit with the architecture of the application rather than the other way around. Here the event handling model adopted by the GUI design tool and the omission of a tool for "wiring up" non-visual JavaBeans limits the usefulness of JBuilder. The systems I work on are mainly processing with a bit of UI and data access on the edges - many systems are mainly UI and data access with a little processing in the middle. If your work falls into the latter category then JBuilder will have more to offer in this area.

I guess the bottom line is that JBuilder provides support for a lot of technologies and activities and that if you want to do something basic in one of these areas then the support will be helpful. But while JBuilder is a "Jack of all trades" it doesn't aspire to being a master in those that matter most to me.