March of the Mac IDEs

Four Java development tools for Mac compared

1 2 3 4 Page 3
Page 3 of 4

Note that you'll need a lot of RAM if you want to run applets from within the Café IDE -- possibly more than 24 megabytes, depending on how loaded your system folder is. Running applets from within the IDE launches the AppletViewer, and between the two, they take up nearly 12 megabytes of RAM.

Although on the whole the environments are fairly stable, it's a good idea to keep in mind that these are still beta-quality IDEs, and you'd be wise to save your work often. None of the environments are completely immune from the occasional crash.

All of the environments, except for Metrowerks', exhibited stability problems when using the classes in the java.net package. To test these classes, I used a chat applet that I developed, as well as the more fully-featured Earthweb Chat applet (http://www.gamelan.com/ noframe/community.html). Kids, don't try this at home. Take my word for it, especially with Sun's JDK, running programs that call the java.net classes can crash your Mac hard -- with or without MacsBug -- unless you're using Metrowerks. (See "Completeness of implementation"," below.) This caveat is true not only of Java development environments, but of Java-enabled, beta versions of Netscape as well.

The failure of most of the environments to fully support the java.net classes is disappointing. One of the great strengths of Java -- the "language of the Internet" -- is the extent to which it simplifies the task of communicating via network sockets. The fact that implementors have had such difficulty just porting the network classes to the Mac is an indication of how much trickier it can be to write network code in C or C++.

Completeness of implementation

API

In their current releases, all of the tools do a fairly complete and faithful implementation of the application programming interface (API). Early releases of Roaster and the JDK had major difficulties with some of the abstract windowing toolkit (AWT) classes, but apparently these problems are gone. You have to look pretty hard to find API implementation bugs in these products. There are still bugs, but for the most part, they are minor ones.

The big exception to this, of course, is the java.net package. Natural Intelligence's release notes for Roaster DR2 concede that Roaster's implementation of java.net is not complete, but they claim that the package will work correctly if the client and the server are on the same machine. I tried a chat client/server pair that I had written, which works fine under Windows 95/NT, Solaris, and Linux; it did not work under Roaster's Applet Runner, even when the client and server were on the same machine.

Symantec's release notes claim that the java.net classes work in Café DR2. In my tests, they failed to establish a connection using the Socket and ServerSocket classes, and left the Mac in an unstable state with regard to network activity until it was rebooted.

Metrowerks wins the prize for the most complete implementation of the Java API. Marcus Jager at Metrowerks attributes the strength of its implementation to the fact that it was based on Metrowerks' PowerPlant class library, a solid, well-written framework that has been the basis for more than a few commercial-grade Mac applications. Sun was impressed enough with CodeWarrior's PowerPlant-based implementation that it chose Metrowerks as a development partner. Future versions of the Mac JDK will be the result of collaborative work between Metrowerks and Sun. Microsoft has also licensed Metrowerks' implementation of the JVM for inclusion in the Mac version of Internet Explorer 3.0.

Stand-alone applications

All of the tools claim the ability to create and run Java stand-alone applications as well as applets. In Roaster, to create a stand-alone application, you simply write a class with a main() method, and designate that class as the startup class of your project. Currently, however, you cannot pass more than one parameter to the main() method, limiting Roaster's capability to run stand-alone applications; there's a workaround, but that doesn't help you run stand-alone applications written by someone else, without editing their source code. Also, the only facility Roaster provides for running applications is to choose Run from the menu in the IDE. There is no way to create a double-clickable application, or one onto which you can drag-and-drop a file.

When you create a project in the Symantec project manager with Café, you are given the option to create either an applet or an application. If you specify "application," the project is created with a sample "HelloWorld.java" placeholder file with the familiar one-line main() method. You specify arguments to main via a text-entry box in one of the Project Options dialog boxes. As with Roaster, there is no way to create a double-clickable application using Café.

Sun's JDK contains an application called "Java Runner," which is an interpreter for Java stand-alone applications. If a compiled class file contains a main() method, you can drag and drop that class file over the Java Runner application in order to run it. If the class file requires command-line arguments in order to be run, a dialog will appear asking you to enter arguments. The JDK also contains a README file detailing how you can use the JDK, in combination with ResEdit and a Macintosh resource compiler (like Rez), in order to create double-clickable Java applications. To do this, you make a copy of the Java Runner application, and then add and edit a few of its resources so that it automatically runs your Java application. The process is a little complicated; it's not for the beginner. Still, the examples included with the Mac JDK do a decent enough job of showing how it's done.

CodeWarrior is the only one of the IDEs that provides a way to create double-clickable, drag-and-droppable Java applications. CodeWarrior supports four types of output for Java projects: a class folder, a "droplet," a zip file, and a "runable" [sic] zip file. Despite the misspelling of "runnable," the choice of the word is unfortunate, as it has absolutely nothing to do with the familiar interface java.lang.Runnable; instead it refers to the ability to run the application or applet by choosing Run from the Project menu in the IDE. Metrowerks deserves credit for CodeWarrior's flexibility in terms of project types, but the names are somewhat counter-intuitive, and do not map well to the choices you get when creating a new project. Sources at Metrowerks indicate that it is revising its approach to make it more intuitive. Incidentally, the fact that you cannot run regular .classfiles from inside the IDE is a nuisance. I imagine Metrowerks is working on fixing that one too.

Native methods

Only Sun's JDK currently provides full support for native methods, although as you might guess, the process is rather arcane -- even more so than on other platforms. Again, the steps are described in a README file and a set of examples that come with the JDK. Native methods are not currently supported for 680x0 Macs, only for the PowerPC. The reason is that the CFM (code fragment manager) extension, which provides support for shared library access, is only available in final form for the PowerPC at this time. Sun says that "support for a CFM-68k run time is being considered."

Metrowerks says that the current version of CodeWarrior's Java plug-in does not include complete support for native methods; however, the Metrowerks Java application includes a javah utility, which can be used in combination with the JDK to create Java applications that call native methods (PowerPC only). The implication seems to be that future updates of CodeWarrior will provide full support for native methods within the IDE.

68k support

68k and PowerPC support is provided by current versions of Roaster, the JDK, CodeWarrior, and -- with the release of DR2 -- Café. Café's JIT, however, is currently implemented only for the PowerPC.

Documentation

None of the products ships with printed documentation. Printed documentation is expensive, difficult to keep updated, and lacks the automatic search and hypertext facilities provided by electronic documentation. Still, electronic documentation is no substitute for a printed manual when it comes to bathroom, waiting room, or subway reading. Call me old-fashioned, but I still find it easier to flip through the pages of a printed manual than to point and click (and wait) my way through a hypertext document. If you have a small monitor, or less than 24 megabytes of RAM, hypertext documents may take up more screen real estate or memory resources than you can afford. Hypertext is excellent in combination with a printed manual, but not as a substitute.

Except for the JDK, which comes with SimpleText README files for documentation, all of the tools ship with documentation in Adobe Acrobat PDF format.

Clearly Roaster's documentation, like Roaster itself, is a promising work in progress. I found it particularly annoying that the documentation for DR2 lacks a bookmarked table of contents. One of the first things I do when I open an Adobe Acrobat file is to turn on the bookmarks on the left-hand side of the screen. I presume that Natural Intelligence will put the bookmarks back in before the final version of Roaster ships, but for now Roaster's documentation, though well-written and thorough, is not much fun to navigate. Although it does not set out to provide as complete an introduction to Java as the full books included in Café and Discover Programming, it does explain basic concepts of Java simply and concisely, in addition to serving as documentation for the IDE.

Roaster also includes a one-click online help feature, whereby you can highlight any method or class from the API where its name appears in your code, and at the click of a button on the toolbar, Roaster automatically opens Altura's QuickView (included with Roaster), with a specially-created version of the hyperlinked Java API documentation. QuickView is a document viewer (familiar to users of CodeWarrior) that allows searching and browsing, as well as the addition of user notes (somewhat like "stickies") at any place in the documentation.

Symantec's Café and Metrowerks' Discover Programming with Java both include excellent documentation. In addition, these two products each come with a complete book in PDF form: Introduction to Java Programming  and Learn Java on the Macintosh, respectively. Of the two, Metrowerks' Learn Java is more thorough as an introductory text, but bear in mind that it is aimed at those with little or no programming experience. Experienced C or C++ programmers learning Java as a second or third language might find the text a little too elementary.

Those who downloaded the original beta version of the JDK will be pleased to find that the README files that come with version 1.0.2 include much more thorough and Mac-specific information. These documentation files are about the most you can expect from a free product that is not itself an IDE.

Speaking of documentation, both Roaster and Café support javadoc-style documentation generation from doc-comments in Java source files. Generating this documentation and having it all appear in a sensible location is as simple as setting a preferred location in the preferences dialog and pulling down a menu item from the IDE. Of the two, Café currently offers more comprehensive support for various nuances of this feature than does Roaster. On the other hand, only Roaster will allow you to create all of the documentation for an entire project with a single menu command; Café makes you do it one source file at a time (although a fix for this is expected in the next version).

CodeWarrior can create this type of documentation as well, but it's not nearly as simple. To do this from CodeWarrior, you have to run the Metrowerks Java interpreter, and in the command window, type:

sun.tools.javadoc.Main /Full/Path/Name  .java

To quote Marcus Jager at Metrowerks, "Getting the output files to appear in a proper location is left as an exercise for the reader." Not very Mac-like, if you ask me.

Note that none of these Mac implementations of javadoc have made any attempt to deal with the "long filenames" problem. Since the HTML files output by javadoc are named automatically from fully-qualified class names (like java.lang.ArrayIndexOutOfBoundsException), they sometimes result in names that are longer than the 31-character limit on filenames under MacOS. As a result, these filenames are truncated by the system, and a Web browser following links to these files will not find them. The only workaround is to keep your class and package names short.

Technical support

Both Natural Intelligence and Metrowerks provide unlimited technical support via phone and email to registered developers for the duration of their subscription. Both companies, and NI in particular, have gone to great lengths to prove their commitment to providing top-quality technical support. NI's java-mac mailing list has been of invaluable help to Mac Java developers, regardless of their choice of development environment. I called both Metrowerks' and Natural Intelligence's technical support departments, and found the staff to be knowledgeable, friendly, and extremely willing to provide honest, in-depth help. In both cases, the person who answered the phone was able to answer my question without putting me on hold.

1 2 3 4 Page 3
Page 3 of 4