Editor’s Note: During a recent phone conversation with Joe Pluta, I found out just how extensively Joe was working with Java (he is a tool-and-die maker) and how diligently he had been looking for the best Java Integrated Development Environment (IDE). I asked him: “So, what does a tool guy look for in a Java IDE?” After Joe rattled on for about half an hour, providing me with his detailed answer, I demanded that he write this article so MC readers would also know how to select a Java IDE.

OK, you got the “Hello World” applet running, and the one with the little guy juggling coffee beans. Now what? Today’s Java IDEs let you build some nifty screens really quickly, but are they actually ready for prime time? Joe Pluta, an admitted tool-anddie guy, examines the available Java IDEs—commercial and shareware—with an eye toward building industrial-strength tool classes.

What does someone like me look for in a Java IDE? Well, that’s pretty easy. I need an IDE that will help me develop high-quality, industrial-strength classes quickly. That means something that allows me to do the following:

1. Reuse old code easily
2. Create new code quickly
3. Find bugs effectively
4. Package code cleanly These prerequisites aren’t necessarily listed in order of importance. In fact, importance depends on the environment. If I’m simply adding a few bells and whistles to some existing code, items 1 and 3 are the most important. On the other hand, if I’m about to tie some things up for shipment, item 4 leaps right up there in importance.

To see if anybody had developed good toolmaking tools for Java, I decided to investigate as many of the IDEs as I could get my hands on. I ended up looking at about a

dozen different vendors. Remember, folks, that this is a very informal review. I procured shareware or limited versions of the products, whatever was free from the Internet, with the exception of IBM’s VisualAge for Java (in a unscientific attempt to keep the playing ground level, I used an old 1.0 version of VAJ). This article is not meant to be an endorsement or condemnation of any particular tool. Instead, it’s meant to give you an idea of what I think is important in an IDE and to show you how some of these features are implemented in various IDEs.

General Observations

I did make some observations about IDEs in general. Stepping back, I could perceive two basic approaches to the IDE concept. The first was the JDK add-on approach. These products sit on top of an installed Java Development Kit (JDK) and make liberal use of the existing Java tools, such as the JDK’s standard compiler and debugger (javac and jdb). KAWA (TEK-TOOLS, Inc. at www.tek-tools.com/kawa), JIG (S-Cubed at www.scubed.cc), and Grinder (The Paradigm Exchange [TPEX] at www.tpex.com/grinder_home. html) are examples of products falling into that category.

The other approach, favored by what I call the brand name IDEs like Borland (oops, Inprise) and Microsoft, uses embedded JDKs and integrated compilers and analysis tools. These are far more capable of intuiting information from your source than the JDK add-on tools. Unfortunately, they tend to be more rigid when it comes to the release of JDK you want to use. This isn’t as much of an issue with a visual programming environment because the visual classes are heavily release-dependent. However, I’m trying to build tool classes, and the JDK restriction is very annoying.

And then there’s IBM. Big Blue’s Java IDE has got to be the most unusual tool of those I have examined; regardless of what road anybody else is taking, IBM refuses to follow. That’s the attitude that brought us the AS/400, and it’s just as apparent with VisualAge for Java. Everything in VAJ is in a repository. IBM pulls in your nasty, human- entered source code and massages it into something more pristine and machinelike. You will follow IBM’s rules, or IBM will take its bat and ball and go home. But if you can live within that paradigm, IBM offers a powerful toolset.

Up Close and Personal

To run the IDEs through their paces, I decided to attempt a real-world example. I tried to import my existing Java package, AS400FileView, which is essentially a Java- based Data File Utility (DFU), and my existing test program, MemberListViewerApp, and see if I could get them to run. If I managed that, I would attempt to create a new panel that mimicked my Java File Utility (JFU) panel (which, in native Java form, uses lots of layouts). But, as I discuss in “A Look at IDEs from a Tool-and-Die Guy’s Perspective” (a companion piece to this article available on the Web at www.midrangecomputing.com/ mc/99/03), layouts don’t work very well with IDEs. For the record, I never got to the JFU panel, although I did get the application to run on many of the environments, both add-on and brand name. Let’s take a look at the results in a little more detail.

Reuse Old Code Easily

Let’s be honest. Some of the code we write is going to be used over and over again. In fact, it’s been said that all code was written in the 1960s and we’re just reimplementing it—over and over. While I won’t go quite that far, I will admit that some of my better code is classic code. There are a couple of ways to reuse code, and both are necessary to know.

Import Packages

First, I can use fully functional, self-contained libraries of code. These may come from third-party vendors (IBM’s AS/400 Toolbox for Java is a perfect example), or they may be my own code. Regardless of their origins, importing these libraries into my current project should be easy. In my case, I need to import IBM’s AS/400 Toolbox for Java, as well as Swing 1.0.3, if it’s not already available.

TEK-TOOLS, Inc.’s KAWA makes it easy to import outside classes. I simply clicked on the Swing package’s tab, right clicked, selected Add Zip/Jar..., and away I went. Other than an odd requirement that a Win98 registry entry be set to indicate version
1.2 of the Java Runtime Environment (JRE), everything ran relatively smoothly. PLATINUM technology inc./Cosmo Software’s CosmoCode (www.cosmo.sgi.com/ developers/devtools/languages/cosmojava. html), on the other hand, didn’t seem to have a way to globally import classes. As it turns out, there’s an options window for projects that allows you to determine the CLASSPATH to use when searching for classes, but there’s no visual feedback that a specific class is available, as there is in many of the other IDEs.

Importing things into IBM’s VisualAge for Java is not for the faint of heart (or the impatient). Since VAJ is entirely repository-based, every class must be decompiled, analyzed, and recompiled within IBM’s paradigm.

For a package the size of Swing or JT/400, you can be in for a substantial wait (on my Pentium II 450 with 128MB of RAM, Swing took about half an hour to import).

Import/Copy Java Code

Besides using self-contained libraries of code, you may also want to import code snippets, either from disk or from the clipboard. Importing from disk means being able to easily include an existing Java source file in a project, then to rename it without a lot of trouble. To include from disk means making a copy of the source file and then including it into a project. To include using cut-and-paste means opening a window with the file and then copying it in. For the MemberListViewer application, I attempted the import-from-disk method. Despite the different conventions (projects, packages, and portfolios are some of the different terms used by different vendors), I found no great dissimilarities between the tools, with the exception of VAJ. Since VAJ is repository-based, you can import code without making a copy. VAJ reads the Java source in and converts it to its own internal format (which is stored in its repository).

Create New Code Quickly

Writing Java code is much like writing any other object-oriented language. Once you know the basic syntax of the language (which is pretty much the same as C++ minus much of its complexity), the single biggest hurdle is the sheer number of classes and methods. Even with consistent naming conventions, it gets difficult to remember that there is a method called removeAllItems for a JComboBox, but not for a JList. IDEs can help you with such difficulties in a number of ways, and we’ll review each of them.

Syntax Checking

Syntax checking is pretty much standard in all the IDEs. The only difference from one to the other is in the way they present the code. The selected source code file comes up in a regular text editing window with keywords and other program constructs highlighted. Users generally have the ability to change the coloring to their preference. Most editors are basically the same, with the exception of IBM’s VisualAge for Java. With its repository- based IDE, VAJ is a completely different paradigm. IBM breaks apart your source code into separate discrete entities, each editable only in isolation from the others. For instance, my source code for AS400FileFilterViewer is broken into its individual methods. AS400FileFilterViewer has public, protected, and private methods. Each is shown in the upper pane with an identifying symbol while the selected method is shown in source form in the lower pane.

Code Completion

A couple of the more complex IDEs provide a nice feature that I call code completion. What code completion does is provide appropriate information when you pause for “think time.” For example, if I have a variable jComboBox1 and I type jComboBox1 and then I pause, an IDE with code completion (such as Inprise’s JBuilder/400) will pop up a list of candidate methods and variables (including removeAllItems).

Similarly, once I select removeAllItems and then type an open parenthesis, I’ll get a pop-up menu showing the various parameter options, which is particularly useful when creating a new instance of a class. For example, when creating a new JTable in Visual J++, I get a scrollable list of the various ways I can create a JTable, with the required parameters in bold. The code-complete feature makes it easy to complete the method call and go on to the next statement.

Class Browsing

The IDEs that provide code completion also have good point-and-click class browsing—a highly productive feature that allows me to quickly find out the characteristics of my variables. I may have no idea what is in a given variable, but often the IDE does. If it does, it can tell me. Some IDEs even allow me to go to the API documentation for the class or right into the source for the object. These capabilities are especially important when I’m browsing example code, trying to make sense of what somebody else has done (for a tool- and-die guy, that’s the way we learn: take it apart and put it back together again a little differently).

Neither class browsing nor code completion is a necessity for a toolmaker’s IDE. If you choose not to go the brand-name route, you simply make sure you have access to the documentation for whatever APIs you are using. In fact, this may be the smartest route for true tool-and-die guys. Many of the brand-name IDEs have a certain release of APIs embedded in them as well as documentation for that release level (for example, JBuilder/400 is at JDK 1.1.5) and you’re locked into that release. In general, tool builders need to be able to use the most advanced versions of the available components in order to build truly successful tools. Carefully review your business decision if you choose an IDE that locks you into a specific JDK release. In fact, for me, the true comparison of the embedded JDK tools will be to see which one incorporates JDK 1.2 first. Design for change is the name of the game when you’re building tools.

Compiler Errors

Here’s a crucial issue. How does the IDE tell you about errors? Tool builders tend to push the envelope of syntax a bit. Because of the flexibility of configurable tools, it’s not unusual for tools to use five or more levels of indirection to get a value. Here’s a relatively tame example:

(cm.getColumn(j).getHeaderValue().equals(view.getFields()[i].getName()))

When we mistype something in the middle of that, we’d like to know exactly what we did. The tighter the integration between the compiler and the editor, the more productive we are. Not surprisingly, the brand-name IDEs did a much better job on this score. The JDK add-on IDEs usually show you the error output from javac then point you to the source line that caused the error. JBuilder/400 immediately highlights the line and positions the cursor. Visual J++ even provides context-sensitive help.

Help Support

This is an interesting area for a tool-and-die guy. While I don’t like to admit it, I do use help. In fact, since I probably just fired the IDE up and started coding, I’m more likely to use the help than someone who actually reads the manual. I’m not going to go into a big diatribe on what I would put into a help system, but I’ll say this much: Help text that looks like a copy of an HTML Web page is not nearly as effective to me as a good text-based help file with accurate hyperlinks and a decent index.

I found that the help systems were all over the board. TPEX has an extensive set of reference materials, including tutorials, while KAWA is bare bones. CosmoCode and SuperCede (SuperCede, Inc. at www.supercede. com) provide good reference materials, but they are not much good for learning Java coding techniques.

In tool-guy mode, I usually need to search the entire document based on a word because the “intuitive” way doesn’t help. For example, when trying to import a Java

package, if I don’t find it easily accessible on the menu, you can bet I’m going to want to search the entire help text on the keywords “import” and “jar.” For that, I have to give an annoyed but affectionate slap upside the head to IBM for its Help Search Server concept. You have to load a separate standalone search engine to search the IBM documentation. This is a radically silly concept, especially since I could never get the thing to work (it failed on an inability to open my local host). I’m sure that when it works, it works wonderfully since the rest of the IBM documentation is thorough and professional, but the search server needs to be much better integrated.

Examples and Tutorials

This is another area I don’t talk about often but use unabashedly. I love looking through example code and tutorials, especially when they have good cut-and-paste support. A big factor for me when rating an IDE is to see exactly how much example material there is for me to...study.

Find Bugs Effectively

The next important thing to consider in an IDE is the ability to find and squash bugs as quickly as possible. Normally, I run my program and find that it bombs (I have, of course, written programs that worked perfectly the first time; both of them were variants on “Hello World”). Often, I know what the error is just by looking at the results. I change the source code and retry the program. However, there are those times when I just scratch my head and say, “That’s odd.” Those situations require true debugging (getting into the code while it’s running to determine what’s wrong).

The act of debugging is simple: Stop program execution at some point and see what the state of the program is. When the program stops behaving the way I expect it to, I then need to find out why. I’m not going to go into detail on how to debug, but I do have some specific requirements from my IDE for debugging, and here they are:

• Breakpoints. I define a breakpoint at a specific line of code where I want the program to stop. For the most part, if an IDE supports breakpoints at all, it supports only simple STOP HERE breakpoints. While these are the only essential breakpoints, other breakpoints can make life much easier. For example, a conditional breakpoint allows me to say “STOP at this statement IF this condition is met.” This requires much more work on the part of the debugger but can greatly boost productivity in complex programming environments. Figure 1 shows an example of a conditional breakpoint window.

• Watches. Few tools afford the watch option, which, frankly, is far more useful for older programming languages with global variables. In the old days, I could never tell when a given variable was being updated; with a watch, the debugger shows me the contents of the variable every time execution is halted (this is often used in conjunction with stepping through code). In newer languages, I can encapsulate the variables of a class, which pretty much eliminates the need for this function. You do use get and set methods for all of your variables, don’t you? Your variables are at least modified by the protected qualifier, aren’t they? No? Well, we’ll have to chat about that some day. This article is about IDEs, not programming techniques (for which you may refer to Don Denoncourt’s article “Object-oriented Design for AS/400 Java Applications: Standard Encapsulation Strategies,” MC, July 1998).

• Variable Inspection. Variable inspection is pretty much standard in all the IDEs that support breakpoints since, without it, the ability to debug is zero. To allow inspection, the debugger has to know the class of an object and then allow interrogation of the various variables of that class. I didn’t attempt to trick the IDEs with any badly behaved casting (although I do use a downcast in one of my methods); I was simply making sure I could double-click my way through an object and its variables. IBM’s AS/400 Toolbox for Java objects, for example, has lots of circular references, which all the IDEs handled quite well. I also didn’t check any special features (such as evaluating method calls on the fly) because I simply don’t use them.

Package Code Cleanly

Well, now that I have a well-designed, bug-free set of classes, I need to get them out into the world. That’s the job of packaging. For a toolmaker, there are two completely independent packaging requirements. One is for the utility classes we’ve developed. For example, I want my AS400FileView classes to reside in a package named com.pbd.as400. I need to be able to generate a .jar file containing the appropriate files (at the very least, classes, but I should be also able to include java source, javadoc HTML and even JavaBeans if I am so inclined). My users then place this .jar file in their CLASSPATH, and include my classes with the line:

import com.pbd.as400.*.

I also want to be able to include some demonstration code that shows how to use the new classes. I don’t want to include the demonstration code in the tool class’ .jar file. Instead, there should be a meta-object that has both the .jar file and the demonstration code. This routine really falls into the realm of Java installers, so I won’t deal with it here.

Regardless of the packaging of the demonstration code, the tool should be able to easily and cleanly create a .jar or .zip file (preferably both) for my actual tool classes. Selecting the components should be as easy as possible. KAWA allows easy addition of whatever components you want to your .jar, as shown in Figure 2.

So, What’s the Point of All This?

Well, I think I’ve managed to present a slightly different perspective on Java as a development language and on what is important in Java development tools. Java is not just about writing applets or Web games; underneath the glitzy exterior is a remarkable object- oriented foundation for writing true, industrial-strength client/server tools. And it looks as if the Java IDEs (with minor differences) are, for the most part, adequate for building the industrial-strength classes needed to write the next generation of network-capable applications. As long as you avoid the visual programming environment and carefully review your specific requirements, you should be able to find an IDE to match your needs and budget.

Java has the combined power of IBM and Sun behind it. If you are a serious toolmaker for the AS/400, you need to understand Java and what it can do. You’ll need to populate your own personal toolbox very quickly, and I hope this article helped show you some of the things to look for in the tools you choose. For a list of books, URLs, and other tools that should be a part of your Java toolbox, see the sidebar, “What Else Does a Tool Guy Use?”

What Else Does a Tool Guy Use?

I rely heavily on whatever I can get my hands on that will help me in my job—other people’s tools, references materials, Web sites, you name it. I’m not looking to be a pioneer; I can’t stand reinventing the wheel. Reviewing my personal toolbox, I have a few things I can recommend:

Tools

I keep some general-purpose tools handy that really have nothing to do with Java in particular but make development a heck of a lot easier. Here are a few that I find absolutely indispensable:

WinZip (www.winzip.com) Little needs to be said. You use this; you know you do. U.S. $29.

ReGet (www.reget.com) An absolutely fantastic tool for downloading from the ‘net. Allows multiple downloads, pausing and resuming.

U.S. $20.

NoteTab Pro (www.notetab.com) A great source editor. Allows editing tons of files simultaneously with multiple document search-and-replace (fix the javax.swing problem with a single command!). It also comes with a boatload of features I’ve just begun to take advantage of. U.S. $19.95.

A true tool-and-die maker not only appreciates good tools, but also makes sure to keep other good toolmakers in business. Each of the above programs is shareware, but I have registered all three. Why? Because for $70, I have the satisfaction of knowing I have contributed to three toolmakers whose products I use every single day. OK, I’ll get off my soapbox (for now).

Books

I don’t have an extensive library. I usually find one or two books for each area of information I need, then fill in the cracks with ‘net surfing. More than one reference book tends to confuse me; heck, I can never remember whether things are in the RPG Programmer’s Guide or the RPG Reference Manual (although I’m far more likely to find it in the Reference Manual).

When venturing into new areas, I find there’s usually a standard progression. First, I have to learn the terminology. For a new language, this includes the basic syntax. Next, I need to understand any significant extensions to the language that I will be using. (For instance, when I started my OS/2 project, one of the things I needed to learn was the Client Access Advanced Program-to-Program Communications (APPC) APIs; needless to say, this area was not covered in my basic C texts.) Once I have these basic tools, I then need to learn from experts how they’ve used the language. Since I’m normally heading off into uncharted waters, I often do this purely through reviewing other people’s code and embarking on trial and error on my part. Luckily, though, I have found good references for basic object-oriented design. The books in my bookshelf include the following:

1001 Java Programmer’s Tips (with CD-ROM) by Mark C. Chan, Steven W. Griffith, and Anthony F. Iasi Jamsa Press; ISBN: 1884133320 Even though it’s a little long in the tooth and oriented toward Web development, this is still my favorite basic text on Java. Since the actual Java language specification doesn’t change from release to release, this book keeps its value year after year. I especially enjoy the comparisons and contrasts between Java and C++. Be forewarned, you will not learn the Java APIs from this book. Instead, you will learn how to write basic Java code.

Programming with JFC by Stephen Asbury and Scott R. Weiner John Wiley & Sons; ISBN: 0471247316 This was my bible for learning Swing (Swing is the well-known name of the Java Foundation Classes beta). It’s definitely getting dated these days with the release of JDK1.2, but as a jumping-off point for learning the UI, it’s great. I especially enjoy its treatment of layout managers, which are probably the single most important concept in the entire Java UI.

Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, and Grady Booch Addison-Wesley Publishing Company; ISBN: 0201633612

Pattern Hatching: Design Patterns Applied by John Vlissides Addison-Wesley Publishing Company; ISBN: 0201432935 These two books are the reference manual and programmer’s guide (so to speak) for design patterns, IMHO the single most useful concept in object-oriented development I’ve ever come across. While I can’t go into great detail within the scope of this article, design patterns may well be the tool-and-die guy’s version of the philosophers’ stone. With design patterns, you can transform real-life problems into objects and actions, and then into real programs. Toolmakers of the world, this is the place for inspiration. If you don’t say “Aha!” a few dozen times, you may want to rethink your vocation.

In addition, many developers use the following as API references:

The Java Class Libraries, Second Edition, Volume 1 by Patrick Chan, Rosanna Lee, and Doug Kramer Addison-Wesley Publishing Company; ISBN: 0201310023

The Java Class Libraries, Second Edition, Volume 2: java.applet, java.awt, java.beans by Patrick Chan and Rosanna Lee Addison-Wesley Publishing Company; ISBN: 0201310031

The Java Class Libraries: 1.2 Supplement by Patrick Chan, Rosanna Lee, and Doug Kramer Addison-Wesley Publishing Company; ISBN: 0201485524 (not yet published) These three titles are Patrick Chan’s Java “bibles.” They are very good reference books, but since I prefer online documentation, I tend to use the HTML format from Javasoft. Those of you who prefer hardcopy reference books will want to take a look at these.

The Internet

As you might guess, there are about a million Java sites on the ‘net. Rather than try to review any of them, I’ll simply list a few of the ones I frequent and let you do your own surfing:

Sun Sites developer.java.sun.com/developer/index.html java.sun.com java.sun.com/products/jdk/1.1/docs/api/packages.html java.sun.com/products/jdk/1.2/docs/api/index.html java.sun.com/products/jfc/swingdoc-api-1.0.3/frame.html java.sun.com/products/jfc/tsc/index.html

IBM Sites ncc.hursley.ibm.com/newsgroups/ncc/nccnews?ibmpub.java.os400 www.alphaworks.ibm.com/Home
www.ibm.com/java

Other Sites java.wiwi.uni-frankfurt.de www.developer.com/directories/pages/dir.java.html www.freewarehome.com/programming/java.html www.gamelan.com

<>
<>
<>

Figure 1: The better IDEs have breakpoint windows that allow you to set conditional breakpoints.

<>
<>
<>

Figure 2: TEK-TOOLS, Inc.’s KAWA allows easy addition to your .jar of whatever components you want.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Practical Java: Start Your Java Engine!

Practical Java: Making Java Work for You

Book Review: Java for RPG Programmers