Why VAJ sucks (for web projects)

Some time ago, I had to use Visual Age for Java (VAJ) in a project that involved servlets and java server pages. During this project, I learned to loathe VAJ. While I won't come up with 10 reasons for not using VAJ, I have a few to name.

VAJ looks like it was written as a PhD thesis on incremental compilation and on-the-fly debugging. All Java code is held in a database-style repository; each class and even each method on its own. The repository supports a versioning system; when more than one developer works on a project, a centralized database can be used to hold the repository.

The major strength of this approach is the ability to compile each entity on its own, and to manage different versions of the same class without having to wrangle class paths. In theory, this is all very nice.

The Root of All Evil: The Repository

In practice, the reliance on the repository has a nasty consequence: everything that is not Java code is not part of the repository, and has to be managed as a "resource" in the file system. The nice versioning doesn't work at all for these resources. In a toy application or applet, in which only a few icons and text files are stored as resources, this is not a major problem. In a dynamic web site, a large percentage of the system may consist of HTML, external JavaScript, external CSS Stylesheets, Flash files, GIF and JPG images, and JSP pages. None of these is versioned; many of these - especially HTML and JSP pages - have to interact directly with Java code: calling servlets with form parameters, redirecting to URLs, etc.

To keep track of resources, a versioning system is needed. The VAJ versioning system can't be used. VAJ insists on using its own versioning system for code; there is no possibility to hook in an existing versioning system into VAJ. [Of course, you can export a project to the file system, and import from the file system; but then you have different version numbers in the file system, plus the additional time for thought when a few hundred files are written or parsed.]

Then there are those totally unbelievable non-features: I can't even edit a JSP file from within VAJ, since it doesn't include a text editor! I have to specify an external text editor (which, of course, doesn't know about the Java beans, and can't provide symbol completion or anything else that needs knowledge about the Java classes that are part of the repository). There is no support for java 1.3, let alone 1.4. In addition, the totally ancient WebSphere test environment (ok, i can install tomcat) is so un-integrated that i have to export .class files so that the servlet runner can find them. Oh, and the WebSphere test environment is as slow as the rest of VAJ; it takes forever to start up and shut down, which seems to be an essential part of the debug cycle.

Incremental Compilation and Debugging

So, what about the incremental compilation? IMHO, it is pretty useless. The programmers who created VAJ seem to have missed the fact that most Java classes (at least those that follow good object-oriented style) are fairly small. What's worse, the VAJ built-in compiler is slow, and an external compiler can't be used, for obvious reasons. The (fairly sad) joke is on IBM, since they also provide, with jikes, the fastest Java compiler known to me. In my experience, jikes compiles whole classes faster than VAJ can compile a single method.

The greatest facility of VAJ, debugging with in-place substitution of changed code, doesn't work well when debugging JSP pages, at least when they get a bit more tricky (say, when multiple frames are involved). In my experience, a good logging framework (say, log4j) works better for tracking errors (and it stays in place after debugging and can be re-activated at need).

Caveat: GUI-less projects!

My opinion on VAJ was formed when working on a GUI-less server project: no AWT, no swing, only text output. Some of the features of VAJ, especially the possibility to extend the VAJ workspace with tools written in Java, will be of more interest to people that create full-fledged Java Applications using one of these toolkits.

So, what do i recommend?

For my day-to-day web work, i recommend