WebSphere Studio Application Developer (WSAD) is the successor to the VisualAge Development environment. Those who hated VisualAge will find that WSAD takes a step toward more conventional IDEs. Those who grew to love VisualAge will be pleasantly surprised that although WSAD looks like most of the other IDE clones out there, most of the things that made VA so useful are lurking right beneath WSAD’s surface. Even better, most of the things they learned to put up with in VA are gone. In this article, I’ll provide an overview of WSAD, highlighting the product’s best features and pointing out a few areas where it’s lacking.

The perspective
WSAD introduces a number of interesting paradigms to the world of development environments. The most important one is the concept of the perspective. In the WSAD environment, every phase of development centers on this concept. The WSAD glossary defines a perspective as, “A group of views that show various aspects of the resources in the workbench. The workbench user can switch perspectives, depending on the task at hand, and customize the layout of views and editors within the perspective.” Figure A shows the workbench Java perspective.

Figure A
Workbench Java perspective

Half brother
WSAD is based on the IBM-sponsored open source IDE Eclipse. Except for the location of some menu items, Eclipse and WSAD look exactly alike, but they are not the same product. Eclipse feels a little more mature, and WSAD has more features to attract the corporate developer.

Eclipse does have some nice finishing touches that are missing in WSAD. For example, the code completion support in Eclipse is smarter and more configurable than WSAD.

On the other hand, WSAD definitely targets the corporate programmer, with built-in support for J2EE, profiling, XML, and Web application development. These extras are available in the form of additional perspectives.

Code editor
The built-in editor is top-notch and customizable. It has a code formatter, automatic type import, tab customization, and auto code completion, known as code assist. One of the most hated/loved features in VisualAge was the one-method editing paradigm. In WSAD, you have the choice of editing one method/property at a time or editing the whole class file at once. Unlike VisualAge, both views work equally well.

What’s missing from the editor entirely—which will certainly frustrate many users—is keyboard mapping. There is none. Eclipse has the same problem. The difference is that in Eclipse, the lack of keyboard support is documented and explained. In WSAD, there’s no support and no mention of the missing feature.

Local source code control
WSAD keeps track of local source code modifications and provides a way to view differences between versions and roll back to a particular version. The current version of the source file is just a regular file on your hard drive. Unlike VisualAge, there’s no need to import and export files to and from a repository.

The Classpath
Classpath settings in WSAD are a step forward for development environments and are ideal for anyone who maintains multiple applications using different versions of the same class libraries. Classpaths for each project are separate from each other. If you have classes you want to make available to WSAD projects you can set up a classpath variable that points to a jar file or directory. You then map that variable to your application.

An advantage of this system is that you can have multiple versions of the same library available to separate projects. The system is also flexible. You can add jar files and directories directly to your project’s classpath without using the workbench classpath variables. Figure B shows the classpath for my setup.

Figure B
Classpath setup

Debugging is a separate perspective. This means that the screen setup for debugging can be saved between runs. Multithreaded debugging is simple and straightforward. The only major problem with WSAD debugging is that you must restart the application for code changes to take effect.

Refactoring is a hot topic, and it is straightforward with WSAD. Refactoring involves highlighting an object and selecting a refactoring task from an object’s context menu. A series of dialog boxes then guides you through the steps to accomplish your task. The refactoring tool locates and changes references to your object in other classes. Built-in refactoring wizards simplify moving classes, extracting methods, and renaming variables.

More on refactoring

For additional information about refactoring, check out “Moving procedural libraries into object-oriented frameworks.”

WSAD has a built-in to-do list. This isn’t your ordinary action item list. Since the to-do functionality is baked into the development environment, it’s actually useful. For instance, you can set a to-do item in a specific method at a specific line. When you double-click the item in the to-do list, the source file opens and scrolls to the line that the item is associated with. In the editor, an icon indicates that the line has an associated to-do item. If you place your mouse over the icon, the text of the to-do item is displayed. No special comments are used in the source code file.

In addition to letting you create your own tasks, WSAD automatically creates tasks for you. All compiler errors and warnings have associated tasks in your task list. As you fix the problems, the tasks are removed from your list.

WSAD does suffer from a number of mildly frustrating bugs and missing features. As previously mentioned, there’s no keyboard mapping. Here are some other areas of weakness:

  • Code macros
  • Auto indentation
  • Importing

Code macros, those little bits of code that you use all the time and like to insert automatically by using a keyword, are nonexistent when editing Java source. The interesting thing here is that code macros are available if you’re editing XML, HTML, or JSP files.

The auto indent feature doesn’t work correctly. In one case, when Indention was set to three spaces, the auto indent indented four places, and instead of spaces, it inserted tabs. The code formatter always corrected the problem, but it’s annoying to have things out of whack when maintaining code. And reformatting the entire file to make things right isn’t always a good solution.

Auto imports don’t work at all when using code assist, or the feature is missing. When I select a class name from the Code Assist drop-down list, I want the class to be imported with the class name inserted at the current cursor position. Instead, WSAD inserts the class name including the package name. I couldn’t find a setting to change this behavior.

Basically, WSAD is solid. It has most of the features you’d expect from a modern IDE, and it includes some you won’t find in any others. The local source history, refactoring, debugging capabilities, and integrated task manager are big plusses. The lack of keyboard mapping, code macros, and minor bugs are obvious signs that the product is in its first incarnation. If you need the extra J2EE features WSAD offers, go with it. Otherwise, go for its slightly more mature half brother, Eclipse.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays