Java IDEs for the PC

I found it strange that Java, developed by Sun engineers on a Unix platform, would get development tools faster on alternative platforms (Mac and Wintel). It quickly became apparent, however, that the toolmakers on those platforms had designed their systems to absorb a lot of rapid change as a survival measure. The fact that Java was at least visibly very similar to C++ made adaptation easier than one might expect. Since I use a Windows 95 box to develop Java classes, my quest for an IDE focused on offerings that worked well on this platform.

The two popular commercial Java IDEs that are available (released products as opposed to trial software) are the Borland 5.0 C++ IDE with Java Enhancements and the Symantec Cafe Java development environment. Two other IDEs are working their way toward release status — SunSoft’s Workshop, Microsoft’s Visual J++ environment (formerly called Jakarta), and one environment that is being shown in its alpha state called “Project Eleven” from Visix. There are some freeware and shareware tools; some of the newer ones such as WebIDE and Kalimantan showing great promise. WebIDE is implemented inside a Web page! None have reached the refinement of the GNU C/C++ tools or the level of the commercial offerings yet, but they show the strong commitment on the part of the Java community to provide quality, usable tools for free.

What do I do with an IDE? I use an IDE for three development activities: developing new utility code for applets and applications, developing utility classes for applications (mini-applications), and developing classes for Web pages (or applets). The challenge is the different environment requirements of each activity.

I rate the IDEs by my ability to get productive work done while using them. The baseline case is using a text editor like PFE (programmer’s file editor) 6.02 with key bindings to run the Java compiler, interpreter, and appletviewer.

Let’s consider the canonical IDE, which contains an editing feature, a project management feature, a compilation environment, and a debugger.

Compilers

Both Borland and Symantec have their own Java compilers. Rather than using the javac compiler that is supplied by Sun (and written in Java), these two compilers are written in C and C++. This is a good thing because, while it was a useful exercise to write a Java compiler in Java, for development work you don’t want to pay the speed penalty. The other advantage of writing your own compiler is that you can produce error messages that the IDE can parse such that the editor is automatically positioned over the offending line in the source code. Both environments get a “thumbs up” in the compilation department.

Both Borland and Symantec let you run the appletviewer from the IDE to “test” your code. Unfortunately, neither implementation is very good. (Both use the Sun appletviewer code, which means that Sun’s implementation isn’t very good.) The code was written to work on a command line, not in a graphical IDE. This creates two shortcomings: First, the error messages are sent to standard out (the command window), and second, you don’t get to use the “dump state” key. The Borland environment also gets negative marks for putting the item to actually run the appletviewer under a pop-up menu labeled “View.”

It’s unfortunate that Symantec starts the appletviewer in a DOS window and then closes the window as soon as the appletviewer exited. When the appletviewer produces some strange message like (Class ‘foo’ not found), which would be useful in diagnosing the problem, that information is lost abruptly when the DOS window vanishes. Borland does better by capturing this information into its status window (which Symantec does in “debug” mode), but the status is in with a bunch of other things and can get lost among the text messages. I give Borland a marginal (“horizontal thumb”) and Symantec a “thumbs down” here. This situation is also true for Java applications that run outside of the appletviewer directly from the command line. Again, Symantec throws away potentially valuable information being produced on the command line while Borland captures it into its status window.

Debuggers

Debugging is a different story yet again. Both environments suffered in this area because debugging was being developed at the same time that Sun was designing the interface for debuggers. Symantec has a tremendous lead only because it invested significant effort in its debugger for the 1.2 release, while Borland is still shipping its 1.01 release with the old debugging stubs. Furthermore, the Borland debugger is poorly documented and hard to find. (You can’t use the “debug” button — that is for C programs. You have to use that “View” menu off the target in the project window to start the debugger. Also, as Borland has the “old” Sun debugger code, it pops up a window to connect to your PPP provider if you aren’t on a TCP/IP LAN. Symantec has better variable displays, and it is easier to see and track breakpoints. For debugging, Symantec is “thumbs up,” and Borland is “thumbs down.”

Editors The editors are a central area of both environments. Text editors are like romances — the first serious one you have will affect your view of all future ones. To deal with such user biases surrounding editors, both the Symantec and Borland editors are very configurable. Both come with some canned key mappings that let them emulate various popular editors, such as Brief or Epsilon. Both editors do some syntax coloring to allow you to see structure without reading an entire file (although the Borland editor treats Java code like C++ code, ignoring some Java keywords like “extends”), and both editors allow customization to some degree. Symantec’s editor is the simpler of the two. Configuration consists of binding keystrokes to built-in editing commands, setting prefences for various colors, and binding macros to keys. It is simple to use and reasonably intuitive. The downside is that really interesting configurations are simply not possible. Still, as an editor it gets a “thumbs up” from me. One of the most widely advertised features of Borland’s IDE is that it is completely configurable because the user has access to all aspects of the configuration language CScript. For me, the question “Why isn’t CScript Java?” immediately came to mind. The answer: “Because we already had CScript before Java was released.” I’m waiting to see what their follow-on product does. While I don’t doubt the validity of this claim, I have found that doing anything except simple reconfiguration of the editor involves fairly complex steps that will take many hours to master. What is most disturbing here is the jump in complexity from a macro that inserts the comment characters for a documentation comment, to one that inserts such a comment with some fields filled in, such as author and version. Even with the extra cost documentation, it will be a while before I venture into those thorny regions of the system. In the final analysis, although the editor gets a “thumbs up,” it can do a lot more if one has time to learn yet another programming language (CScript).

Project management

The last required feature of any IDE is project management, which both the Borland and Symantec products offer. Project management has both a source-code management flavor as well as a version control flavor. Since Borland is a C++ environment with Java support (as opposed to a Java environment exclusively), it has a much richer project manager that includes in its Developer Suite a somewhat neutered version of the PVCS version control system. Since the Symantec system has no version control at all, it is clearly at a disadvantage here. Borland gets the “thumbs up” for version control, and Symantec gets “thumbs down.”

The other half of project management, though, is managing dependencies and expressing the structure of the project; Symantec, because it isn’t a C++ environment, actually does better in this regard.

Applets provide a concrete target for a Java IDE. They are identified by an APPLET tag on an HTML page and the classes they use are bundled together, usually in the same directory as the HTML page. As this is not very far from the C++ application model (with the exception that C++ libraries are typically bound into a single .LIB or .DLL file), both environments map well to producing applets. Both Borland 5.0 and Symantec Cafe do a good job of showing the applet and HTML pages of a project as well as building them. Further, if you are building an application like HotJava, you can manage it equally well with both systems (unless you are part of a team of developers, in which case the Borland environment appears to have some features better suited for sharing code). The difficulty comes when you are building a package of Java classes that is used by both an applet and an application, or by multiple applets and applications.

When you develop Java classes that are used by several applets or applications, you need an IDE that understands this dependency, and rebuilds when necessary. Also, the notion of breaking interfaces is critical in Java as the language is late-bound, and a class change can cause a large number of applications to begin failing when you make an incompatible change. Neither system truly manages this sort of environment. To do so will probably require a database of all classes under development in all projects, as well as their dependencies. This can be “simulated” somewhat by creating sub-projects in both systems, but it is not yet complete.

Also Java-specific in the Borland and Symantec environments are the “just-in-time” (JIT) compilers. They work reasonably well in both IDEs. The Symantec-generated code “feels” faster, but I haven`t benchmarked the results for an objective overview. On the other hand, Netscape Navigator uses the Borland JIT compiler, so getting a good result out of that JIT compiler will ensure fast performance under the Netscape browser.

Because the Borland system includes the C and C++ compiler, it is possible to write native methods using it. This is very useful when designing Java applications; less so for applets. If you must have native code, your only choices at present are using Borland or doing it manually with the notes from Sun, the JDK, and the Microsoft VC++ compiler.

Which is better?

Of the two systems, I prefer the Symantec product. However, neither is the ideal environment yet. I’m hoping to get copies of the follow-on products, when they are available, to try out and see how they have improved. One feature of the Symantec system I particularly approve of is the smaller footprint in terms of space taken on the disk. While I seem to have about 20 megabytes allocated to Symantec, the Borland tools consume over 100 megabytes of space. Since I’ve got an IOMEGA zip drive, a really pleasant environment consists of a ZIP disk with the JDK source release, the Cafe’ product (without sample code), the SDK binary release, and a copy of Netscape Navigator as a test platform. They all fit with plenty of room for my applications and applets.

Who and what is on the horizon?

There are three packages on their way out of the lab and into production. Interestingly enough, they all suffer from a bit of hubris. Also, Borland and Symantec are developing new products — called Latte and VisualJava, respectively.

The Java Workshop is a Sun tool. The current release (Dev5) has all the components of a traditional IDE, but it doesn’t work with the current release of Sun’s own JDK. Furthermore, applets designed with the “Visual” tools require that a 375-kilobyte collection of classes be available on your Web site in case the person viewing your applet doesn’t have Workshop installed and in their class path. I don’t expect this package to make inroads into the Windows 95 market.

Microsoft’s Visual J++ (aka “Jakarta”) is an integrated Java/Web development package. This package has the most muscle behind it in the Windows 95 space. However, as with Sun, the programmers at Microsoft can’t keep themselves from putting proprietary “enhancements” into the product to increase the product’s value. Historically, this strategy has backfired. The only notable exception has been Netscape Navigator, which walked all over the HTML “specification” to enhance its value. It has succeeded by being distributed for free, which brings the cost to zero dollars of adopting incompatible changes. Perhaps Visual J++ will follow this model and be free as well.

Finally, there is “Project Eleven” from the folks at Visix. Eleven is not a fully-formed IDE yet, but it is clear from the company’s literature and its showings at JavaOne that Visix has set its sights on the Rapid Application Development market — a market that Borland currently dominates with Delphi, and that both Borland and Symantec are targeting with their Latte and Visual Java products respectively. Visix is best known for its Galaxy system, which provides a feature-rich set of classes for constructing applications. The weak point, shared by Sun at the moment, is that you need Visix’ library (which is in machine code and therefore not portable) to call its class functions.

I suspect these vendors are looking past the individual programmer/engineer toward the MIS department of Fortune 500 companies. These departments are specifying and building intranet applications that will sell a lot of tools. CIOs like Java because of its portability, and the vendors want to somehow attach to their Java tool a strong incentive to go with their OS platform (with the exception of Visix, of course).

Where do we go from here?

Sun`s fiscal calendar begins on July 1st. July 1st, 1996, marked the first year of Java’s existence as a supported product from Sun. I believe that between now and next July 1st we will see Java-specific IDEs being deployed in earnest. There are two clear target customers: big corporate MIS departments and individual developers. What is less clear is what the dominant Java applications will be — applets, applications, or intranet systems.

One possibility is that Java will take a page from the LISP community and, in conjunction with an editor like Emacs or perhaps using a “browser” metaphor, become an environment unto itself, supplanting and replacing the current user interfaces. Certainly, some would like that to happen, but the current environment is too overwhelmed with opportunities to produce any coherent picture of progress toward this goal yet. This sort of environment would be closer to the original Oak environment. If I could create an icon for editing files with the following Java code, it would be a powerful thing indeed:

public class FileEditor extends Tool implements Drop {
    public void init() {
    myIcon = new Image("paper.bmp");
    }
    public void drop(Reference reference) throws InvalidDropTarget {
    Editor e;
    switch (reference.type()) {
        case TEXT_FILE:
        e = new EMACS(new KeyBinding("chuck.key"));
            break;
        default:
        throw new InvalidDropTarget();
    }
    FileInputStream f = fileFromReference(reference);
    e.start(f);
    }
}

Until next month.