Journal Articles
| Browse in : |
All
> Journals
> CVu
> 123
(22)
|
Note: when you create a new publication type, the articles module will automatically use the templates user-display-[publicationtype].xt and user-summary-[publicationtype].xt. If those templates do not exist when you try to preview or display a new article, you'll get this warning :-) Please place your own templates in themes/yourtheme/modules/articles . The templates will get the extension .xt there.
Title: JBuilder 3
Author: Administrator
Date: 03 May 2000 13:15:36 +01:00 or Wed, 03 May 2000 13:15:36 +01:00
Summary:
Body:
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.
When I'm developing software the three tools I use most are a word processor, an OOAD package, and a source editor. Of these the IDE only contains the source browser/editor. Consequently this is the part of the user interface I expect to interact with most and therefore the most important. (Well, it would be, except that having a decent editor is so important to me that I have abandoned the weak offerings provided in various IDEs.)
The editor in JBuilder provides the basic functionality, although I don't like any of the supplied key-bindings and there doesn't seem to be a way to set up alternatives. To take a "for instance", most of the products I use will indent (unindent) blocks of lines using tab (shift-tab) - a common activity, with a single action. In JBuilder this is an awkward double action - Ctrl+K-I (Ctrl+K-U). The "auto-indent" feature is also fairly primitive, taking no account of the language (one has to unindent before entering a closing brace). I find the multiple-file text search facilities somewhat limited (e.g. you are shown the files containing matching lines, not the lines themselves).
This wouldn't bother me if it were simply a matter of switching away from JBuilder to an external editor. However, Borland has had a long standing policy in IDEs of compiling directly from the edit buffer and only touching the disk on an explicit save. (Clearly many people have far more faith in the stability of Windows as a development environment than I have.) The result of this philosophy is that JBuilder doesn't have the option of automatically saving files when it loses focus - something that I find avoids accidents. At least it does automatically reload files that have been modified externally.
On the plus side there are useful browser panes for selecting the source file within the project (or amongst the open files, or within the directory) and the class member within the current file (these browsing facilities fall short of the "class browser" functionality I've seen in some tools). Having selected the current file it is also possible to switch from the text editor to the GUI design tool, the bean design tool or the documentation tool (these replace the text editor pane.)
At first sight this looks like a serviceable, but unexciting GUI builder, but it really disappointed me once I started trying to use it. There are three problem areas: it is buggy, the code it generates is poorly designed, and (possibly as a consequence of the previous item) it doesn't permit effective use of the event "listener" idiom that has supported Java event handling since the early day of JDK1.1.
I encountered one of the most obvious problems when I created a panel with a few buttons on it, switched to the source pane (partly to see what code was being generated) and made a few code layout changes. Then I switched back to the design pane, only to see a blank grey rectangle where my panel had been! It was some time later before I discovered that by right-clicking and selecting the current "look and feel" that the panel could be restored to visibility. Generally I found it very intolerant of code changes: less so than the first versions of VisualCafe and VisualAge Java that I used a couple of years ago - and JBuilder is at version 3.
I guess I should know better than to look at automatically generated code, it always gives me an uneasy feeling. The code generated by JBuilder's GUI design tool is no exception. In the original JDK 1.0 it was necessary to subclass dialogs and other windows in order to handle events, but this was fixed long ago in JDK 1.1. In addition, the content and layout of a dialog should be controlled by its state, not by its taxonomy. For example, one can (and, in most circumstances, should) create a JDialog and specify its contents, layout, and the actions it can invoke without creating an additional class. This increased flexibility is not reflected in the generated code - although it uses the syntax of the revised event model it has stuck with the old design: for example a class MyDialog will be derived from JDialog and anonymous local classes (or optionally, named classes) will be used to forward UI events to member functions of that MyDialog.
I was expecting to be able to use the GUI design tool to attach UI events to methods on any accessible objects - the motivation behind the change to the Java event model was to support this (because the original approach becomes unbearably clunky). In fact this facility is so desirable that IBM even engineered on top of the 1.0 event model in the first release of VisualAge. If IBM was supporting this two years ago in the face of resistance from both the language as then defined and the old event model, then surely Borland ought to have caught up by now! Introducing the unnecessary MyDialog class and routing all messages to it seriously impacts the coupling of the resultant code as MyDialog needs to "know" about all the messages and all the sinks (although the code you write within it may forward again to a sink, redirector or broadcast object).
Many GUI design tools lack proper support for internationalisation and localisation and JBuilder is no exception. The standard Java library provides support for "resource bundles" which are managed according to the current "locale". Text strings used in the user interface should be held in resource bundles. JBuilder takes the less flexible approach of hard coding the strings into the generated code (and the GUI design tool doesn't grok code written this way). Admittedly there is a separate "Resource strings" wizard available to update classes to use resources in place of hard coded strings, but it seems a shame that this approach isn't integrated into the design tool.
One of the many technologies in the Java family is that of "JavaBeans". This standardises the way in which Java components are built and combined. At one level it is a set of criteria that a class must meet before it is considered a "JavaBean" (it is usually "a class" - it is possible to use two classes to make a JavaBean). At another level it is a way of ensuring that components from different suppliers can be used in the same system and can be manipulated by any component assembly tool.
The JBuilder browser includes a class design tool that automates achieving conformance to the "JavaBean" specification by generating the "boilerplate code" required by the standard. This is fine, but when it comes to support for using JavaBeans things are not so wonderful. Some JavaBeans are graphical components and can be handled to some extent in the GUI design tool although the limitation imposed by directing all event notifications to the container is a pain. Other JavaBeans are non-graphical and the support for assembling these is even more limited.
In JBuilder "enterprise" there is also a Wizard that creates "Enterprise JavaBeans" [EJB], these conform both to the JavaBeans specification and to a number of additional criteria (such as supporting the creation of proxies) that allow them to be deployed in a distributed environment. Don't assume that this is only for vast applications running on networks of computers - the "distribution" may only be between different processes on the same machine. This use of Java goes beyond my area of expertise so I can't comment on the effectiveness of this tools beyond the fact that I could quickly create a test program that ran successfully without taking time to learn the detail of the EJB specification. (Clearly Wizards are no substitute for knowledge, and in a production environment I'd want at least one team member to understand what is going on - but it is definitely easier to start from a working model.)
It is hard to get excited about debuggers in general (in truth, I don't use them much), and it is hard to get excited about this particular one. The basic functions (breakpoints, thread status, and so forth) are all supported. One disappointment to me is that a favorite technique of mine - directly invoking a debug method - dumpStatus() or checkInvariants() - from the debugger isn't supported. Basic expressions can be evaluated, but those invoking method calls lead to the slightly mysterious error "not supported: remote method call".
The debugger worked quite happily with both the supplied JDK and with the IBM1.1.7b JDK that I added, however it doesn't support JDK versions prior to 1.1.5.
Since it is possible to have several projects open simultaneously it is possible to start multiple debug sessions. Naturally, each project may be using a different JDK - so with a bit of fiddling about one can debug the same code side-by-side under different JDKs to check for differences.
Another use for multiple debug sessions is to debug both the client and server of a locally "distributed" application. In the enterprise variant of JBuilder there is a facility for "remote debugging" on any target platform that has a reasonably recent JDK version (I didn't have the opportunity to try this).
To facilitate the development and testing of servlets in JBuilder "enterprise" Borland have incorporated Sun's free "Java Web Server" (this is also available at http://java.sun.com/products/). Using a Java based web server allows servlets to be debugged by running the server under the debugger. (By forcing this web server to use a non-standard port address, I persuaded it to run alongside my normal Apache web server as a test environment.)
For many routine tasks there are wizards, one that I really liked was the "packaging wizard". This takes a project, examines the dependencies on library classes and constructs a tree showing the packages required for the project to run. The nodes in this tree can then be checked for inclusion in the ".jar" archive in which the project ships. (No excuse now for forgetting that utility library used once in some dusty corner of the program.) This wizard is in all three variants.
I was rather hoping that the "Javadoc Wizard" would be a tool to aid in the generation of "doc comments" that are consistent with the code. But it isn't: it is simply a shell around javadoc giving a GUI version of the command line switches.
JBuilder "enterprise" has an "application generator" that automates the separation of a server application engine and a client user interface. This supports three options for communication: via "CORBA", via "Java RMI" and by "HTML" (the last may use JavaScript and requires Netscape 4 or Internet Explorer 4 on the client).
There are a variety of wizards for generating the skeleton code for applets, servlets, applications, frames, panels, etc. These generate a couple of basic classes (and possibly a web page for an applet to be displayed in) and load these into the edit/design tool. The number of these wizards available increases from JBuilder "standard" through "professional" to "enterprise" but many of them are not mentioned in the literature.
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.
Notes:
More fields may be available via dynamicdata ..