Linux-Friendly VisualAge for Java

A month or so ago, I decided it was time again for my periodic scour of the Internet for a useful Java debugger (JDB) on Linux. I knew there was a JDB interface built into the Emacs JDE (http://sunsite.auc.dk/jde), but it doesn’t yet have the full visual whiz-bang features to which I became accustomed during my Windows experience. My search yielded a handful of results–some good, some not so good. Most of the better leads, in fact, came from banner ads on Blackdown.org, the organization which makes the free software port of the Java Development Kit for Linux.

I installed a host of integrated development environments (IDEs), hoping that somewhere inside would be the debugger I was seeking. I tried a package called Simplicity (www.datarepresentations.com), which was too slow to be useful. I then tried the experimental FreeBuilder (www.freebuilder.org), which I was unable to compile (neither, for some reason, could I download their precompiled version). They’re still on the bleeding edge, but what they had so far looked promising.

The product I was actually able to use for a while, until instability problems put me back on the trail, was a German software package called AnyJ (www.netcomputing.de). It was easy to set up and use, and their Linux policy is refreshing: "Since we profit from using this OS without being charged and since the feedback and bug reports done by Linux users were very useful, we provide AnyJ for free on this platform. AnyJ is guaranteed to stay free for Linux, as long Linux has less than 20 percent market share on desktop systems, and NetComputing GmbH is the owner and maintainer of AnyJ."

While this isn’t "free" software in the Richard Stallman/Free Software Foundation sense (www.fsf.org), it is free in the pocketbook sense, which is a very attractive feature. I suspect that their Windows offering is less problematic, but their Linux port periodically loses its mind and takes over the entire machine, requiring the invocation of the drastic but effective bludgeon killall jre.

By way of this circuitous route, I found myself at the doorstep of none other than IBM, which appears to be serious about its Linux strategy. Having used IBM’s fast Linux Java compiler, jikes, and its zippy Linux port of the Java Development Kit 1.1.8, I decided to download and install IBM’s Linux port of VisualAge for Java 3.0 (www.ibm.com/software/ad/vajava/linux.html). Compared to all the other similar products I tried on Linux, this one is in a class by itself. It’s fast, stable and extremely full-featured. Unfortunately, it has one fatal flaw, at least for my style of development, but I’ll get to that later.

Standard Features

Installing and configuring VisualAge is a piece of cake. Unlike Microsoft’s VisualStudio, VisualAge doesn’t come distributed across a thousand different CD-ROMs, and you don’t have to install five different service packs to start using the software. There is one CD-ROM for each platform it supports. It comes with copies of the Personal Edition, version 6.1 of both DB2 Universal Database and DB2 Connect for all the supported platforms, but I was never prompted to install them. If you use DB2 for any reason, this is a bonus, but, unlike some Borg-ish IDEs I’ve used, VisualAge doesn’t coerce you into installing a bunch of technologies you don’t really need but that the vendor wants to promote anyway.

Beginning a project from scratch is trivial. Upon starting, VisualAge asks what kind of task you want to perform: create a new thing (a class, interface or applet), continue working on an existing project or perform some administrative function on the Team Server (Enterprise Edition only, I presume). The HTML documentation is well organized, well written and thorough. It is also nicely bound to the application (bless the death of Winhelp).

The bean-builder has all of the GUI-building capabilities you would expect. I was quickly able to build a simple, functional applet. It employs a visual connection metaphor whereby lines of different colors and strengths are drawn between the visual representations of your objects. The different colors and line strengths represent different properties of the connection. For example, a dashed line means that some property of the connection has yet to be established. In general, the information about the relationships between objects is presented in a compact, efficient and intuitive manner.

The visual connection metaphors are intuitive, if you like such metaphors. If you don’t like visual programming, you might find them cumbersome. As the interface gets complicated, the resulting spiderweb of connections between objects can appear daunting. It’s not clear to me that all the work that goes into establishing such visual connections is easier than coding by hand, but at least the metaphor is complete. Of course, if you don’t like visual metaphors, you aren’t likely to use a product called VisualAge anyway (at least not without putting up a fight).

The bean-builder user interface is competently laid out. I was able to determine what and where most features were with only a gentle nudge from the documentation. My usual learning strategy of pointing at things and clicking each mouse button to see what happens usually yielded informative results without mucking things up too badly. There was one notable exception, however. When fiddling with the layout of my example applet, I accidentally duplicated all of the widgets in my container. I’m still not sure how it happened. Unfortunately for me, while trying to rid my applet of the duplicate widgets, I accidentally deleted my originals, not the copies. A few steps later, this caused all my visual connections to be made between unexpectedly named objects, which broke all my hand-written code. I suspect this is a fairly common mistake, which highlights the need for extra special care when crossing the boundary between the IDE-generated code and your own lovingly handcrafted code.

Trying to use VisualAge on an existing project is more difficult. I imported the supporting code for an entire Web site in my first effort to test drive the product, but was completely unable to fit my development process into the VisualAge paradigm. I ran hard into the philosophical disjunction between VisualAge and every coding methodology I’ve ever used and wasn’t able to reconcile it. VisualAge doesn’t use the file system of your computer to store its projects (or your code!). Instead, it stores all the source and object code away inside a repository into which you must check classes into and out. If you want to work on an existing project, you must first import the entire codebase and any supporting classes you need into the VisualAge repository.

This method of handling a project might work well when VisualAge is your only tool. VisualAge provides enough features to make doing so an option, including a versioned change-management system. I must admit, not having to fiddle with my classpath was a bonus. But woe to you if you need to incorporate an outside technology into your development process. The only way to expose your project to the outside world is by exporting either source code or bytecode. If you can’t already see the train wreck ahead, let me provide a simple example which immediately confronted me.

The project I am currently working on is stored in a remote CVS repository. If I want to use VisualAge on my project, I have to import the entire thing into the VisualAge repository. When I’m finished making my changes, I need to export the entire project (or, if I’ve kept track of which classes I’ve modified, I can just export those) back to the file system. When the code is exported, all the original formatting, warts and all, is reworked to conform to the VisualAge formatting specifications. Unfortunately, this tends to confuse diff to no end, rendering the merge- and change-history capabilities of CVS/RCS completely useless. My response to IBM vis-à-vis the wisdom of the repository approach would be an invocation of the Hippocratic oath: First do no harm. If a feature is not useful, you should be able to ignore it. It should never stand in the way of using the entire product.

Enterprise Features

The Enterprise Edition of VisualAge 3.0, which, as far as I know, isn’t available on Linux, contains two categories of features to aid in the development of larger-scale, distributed systems. The first is a set of workgroup efficiency, communication and change-management tools. Support for this is based on a "team server" that lives on a machine to which the entire team has access. The team server manages the code repository and multiuser change control. It also maintains notions of team roles, group memberships and scopes of responsibilities and ownership for the development team. It is perhaps no accident that these terms and concepts in some ways echo the terms and concepts of the object-oriented programming literature.

Members of the team may be subdivided into groups. Projects, packages and classes may each have a member of the team as an owner; thus the workgroup organizational structure is mapped by VisualAge onto the code itself. This workgroup structure is supplemented by to-do lists for team members and different "editions" of code elements, which may belong to different team or group members. If your team process can be mapped in this way, VisualAge might be a powerful group-process management tool in addition to a programming environment. If not, I suppose you can always ignore those features that don’t appeal to you.

The other set of the Enterprise Edition features is perhaps more broadly useful; they are all tools to aid in the development and deployment of a distributed system over potentially heterogeneous technologies and environments. These include "Enterprise Toolkits," database-access tools and a set of distributed object builders.

"Enterprise Toolkit" is a fancy term for a compiler that will compile your write-once, run-anywhere (slowly) Java bytecode down to "code that is optimized for the target platforms where the application will run." This feature begs the question to be asked: "Why are you writing it in Java in the first place?" Why you would use a technology that you knew wasn’t appropriate for the task at hand and then use another piece of technology to rectify those shortcomings is beyond me.

The Enterprise Edition comes with the following:

• Enterprise Toolkit for Workstations (which will build applications to run on OS/2, Windows NT or AIX)

• Enterprise Toolkit for AS/400

• Enterprise Toolkit for OS/390

If your organization employs a high number of existing IBM technologies, these toolkits might help you make a transition from whatever heterogeneous technological goo you must contend with now into a more comprehensive and consistent development approach using a modern object-oriented language. How you manage that transition and ongoing maintenance is up to you.

The remaining Enterprise Edition features seem considerably more useful. These consist of a JDBC application builder (the "Data Access Builder") and a set of distributed object creation tools. The Data Access Builder allows you to quickly generate a Java GUI front end to your JDBC data source. This is useful if you have a set of classes that corresponds neatly to the schema structure of your database. You might find the GUI it generates, based on your schema, works nicely for you. If you have a simple database and a simple set of corresponding data classes, this might well be the case. It’s less clear that you will find much efficiency in this tool if your classes and schema have deep structural differences.

The most helpful tools are the C++ Access Builder, the RMI Access Builder and the IDL Development Environment. The C++ Access Builder provides access to C++ shared libraries from Java (using, I assume, JNI). The RMI Access Builder and the IDL Development Environment aid in the implementation of RMI and CORBA objects and interfaces, respectively. Fiddling with JNI by hand is tedious and tricky. Handling the details of RMI and CORBA is tiresome and boring, what with all of those stubs and skeletons to write. Any help automating these processes is greatly appreciated.

Putting Your Eggs in One Blue Basket

VisualAge for Java is a rich and powerful tool, especially the Enterprise Edition. If you are snug and warm in bed with IBM technologies, this tool may well solve problems for you and provide you with great benefit. It’s fast, helpful, stable and comprehensive. There’s the rub: comprehensive. If you are prepared to commit your development team–or even your entire enterprise–to a single approach and a single development environment, you could do worse than VisualAge and probably not much better. If, however, you are uncomfortable placing all of your eggs in the friendly hands of Big Blue, well … maybe you should take it for a spin and see for yourself.