My Favorite Extreme Programming IDE

I used to be a die-hard fan of the stand-alone source-code editor. You know the type: I fired up my code editor on every project for a wide variety of languages, and could often be heard saying things like "IDEs are for wimps," "My editor handles any language," and "Who needs a debugger? The code I write isn't very buggy." Today, I'm a changed man. My tool of choice for solo or team-based Java programming is IBM's Visual Age for Java Enterprise Edition 3.5 (VAJ). Over the past few years I've found that VAJ is an excellent tool for doing Extreme Programming (XP).

Before I explain further why VAJ is so good for XP, I'd like to get a few things out of the way. First, I have no connection with IBM, so this article isn't a disguised marketing message. Second, this isn't a comprehensive look at all that VAJ provides—it offers a lot, but I'm just interested in showing you how it helps us do XP efficiently. Finally, you may have tried VAJ and disliked it. That happened to me too, in 1998. But the folks I was programming with back then didn't really know how to use the tool effectively, so my perspective on VAJ was warped. When I later pair-programmed with people who really knew how to use VAJ, I was surprised to discover how great it was. So perhaps my experience will help you approach this tool with an open mind.

Living on the Collective
VAJ is particularly great at version control, which is vital for Extreme Programmers, since we collectively own our code (anyone can change anything at any time), continuously integrate code (many times a day), and mercilessly refactor it. With such changes happening so frequently, it helps to be able to quickly, easily and safely view, compare or revert to different versions of a method, class, package or project. While you can do that with nearly all of the popular version-control packages, some of which integrate into editors or IDEs, using those tools is awkward compared to what you get with VAJ.

Time-Stamped Methods [click for larger image] As I'm working on the method, wrap(...), I want to see what an older version looks like. I simply right-click on the method name, choose "Compare With," select "Another Edition," and bang, VAJ gives me a time-stamped list of all previous versions of the method (pictured above). To see the code for each edition, I simply click on a time stamp.

VAJ makes life easy by providing powerful, built-in version control tools that can be accessed via a few mouse clicks. I recall being amazed the first time I discovered that VAJ was storing snapshots of every version of a method I had saved (see Time-Stamped Methods). This feature allowed me to comfortably make changes to a method, knowing that I could easily and quickly revert to an earlier edition with a minimum of effort. Merging code is also easy in VAJ, since it provides convenient comparison views of different versions of a package. Such views simplify the always-difficult task of figuring out how your code changed from its original version to its latest version.

But the real secret to using VAJ's version control on an XP project is to use a simple version-control strategy, which begins with a single user sign-on: We don't care who wrote what code, so everyone logs in as "XPUser." We don't lock code, for doing so would violate XP's collective code ownership practice. And when we version code, we rely on VAJ's clever and simple numbering scheme, which suggests version numbers that reflect what code changes the entire team has already made. We add one simple twist to this—we version only at the project and package level. This means that if we want to modify code within a project (which is essentially a collection of Java packages) or a package, we mark the project or package as an "open edition" and make our changes. Thus, we create a new version by letting VAJ suggest a version number for us and ignoring the version numbers VAJ automatically assigns to the code within our packages (See the "Versioning in VAJ, Extreme Programming Style" sidebar).

This simple way of using VAJ's version control has worked beautifully both in solo practice and in teams from eight to 25 people. And because it is so simple, it enables us to implement XP's continuous integration practice with great efficiency.

No More Big Builds
VAJ's incremental compiler also improves our development speed. In most IDEs, such as JBuilder or VisualCafé, or source-code editors (like SlickEdit, IntelliJ or emacs), you edit a file, save it, and then invoke some command to compile the code or rebuild everything that needs to be compiled. In VAJ, every time you save a method, the compiler kicks in automatically and does the job for you, so there's no "build" menu item in VAJ, no "rebuild" option; not even a "compile" option. Incremental compilation just happens every time you save a method, variable declaration, class declaration, import statement and so on.

VAJ Suggestions [click for larger image] In this method I've used Java's ArrayList class, but I haven't provided an import statement for it. When I save the method, VAJ's incremental compiler shows me the error message(s). If I click on an error message, VAJ attempts to offer a suggested correction. In this case, one of the suggestions is to add the import statement, java.util.*. If I click on that suggestion and choose "correct," VAJ automatically applies the correction.

This feature creates time-saving magic. For example, say I save something that the incremental compiler sees has a problem. VAJ warns me, offering the option of fixing the problem now or adding it to the Problems page and fixing it later. If I choose to deal with the problem(s) immediately, VAJ suggests possible solutions (see graphic). If I choose to ignore the problem for the moment, VAJ saves the code, but places an X icon next to the name of the field, method and/or class containing the problem. These Xes make it easy for veteran and novice programmers alike to immediately see how a change to one part of the code can affect other parts. Compare that to what happens if a programmer makes many changes to some code, then saves, and then compiles, only to find a mountain of errors—sounds familiar? Incremental compilation embodies XP's value of feedback: It gives programmers feedback as fast as possible.

Efficient Debugging
Incremental compilation also makes debugging sessions more efficient. When I was still a fairly new VAJ user, I was pair-programming with a woman at Evant, an application service provider in San Francisco. We were running some JUnit tests, one of which had just failed. A quick look at the code did not reveal the solution, so we decided to use the debugger. We set a breakpoint in our test code, told JUnit to rerun the test, and in a few seconds we were positioned on our breakpoint, ready to debug. We stepped into a method, then another method, and a few steps later we were in the method that contained the bug. We were on line 4, and I spotted the problem on line 2. That's when my partner simply fixed line 2, saved (think "incremental compiler doing its magic"), and then chose a wonderful little option in the debugger that allowed us to re-enter the method as if we had not entered it already! Our test code ran successfully, and I was amazed. We had just changed a line of code while debugging, rerun only the method we had changed (not the whole program) and seen JUnit report that our test had run successfully. It's also worth noting that VAJ has excellent support for debugging servlet-based code, since it can create two separate JVMs: one for the client and one for your servlet.

Automated Refactorings
Refactoring—improving the design of code without changing its behavior—is something Extreme Programmers do all the time. But refactoring manually can slow you down. So VAJ has an excellent refactoring plug-in tool called jFactor (by Instantiations), which seamlessly integrates with VAJ as well as with Borland's JBuilder. When you click on a class or method or highlight some chunk of code, jFactor will provide you with a list of possible refactorings. Choose one, and the tool will ask you for some information—and then safely perform the refactoring for you. The only downside to this tool, at the moment, is that it doesn't support undo, and it isn't cheap. Nevertheless, I'm addicted to using it since it speeds up my refactoring work.

VAJ has excellent searching capabilities, including the ability to easily find all callers of a method or find the methods and fields referenced by a method. It has basic capabilities to move, copy or rename chunks of code. It has capabilities to set coding format standards. And, like so many IDEs today, it has a code-assist feature designed to help you remember which method to call, and what parameters that method expects.

The Competition
We've explored what makes VAJ good for XP and in a moment, we'll look at why VAJ is not so good for XP, but let's now ask "Why isn't it better to do XP using a smart code editor, JUnit and some external version control tool, like CVS?" For example, IDEA's IntelliJ (see "The J Factor," Hello, World! Dec. 2001) is a very good tool. It makes Java coding faster and easier by automating many common coding tasks, provides built-in, automated refactoring support, integrates with version control packages like CVS, and comes with a powerful debugger. That's a strong package! But I've used stand-alone source editors and CVS on XP projects and I've found that they don't work as well as VAJ when a team is collectively owning their code, continuously integrating it and mercilessly refactoring it. VAJ's version control is simply a joy to use on an XP project—its incremental compiler speeds development by avoiding lengthy builds, saving precious time when you're frequently refactoring and integrating; and VAJ's plug-in, jFactor, includes support for an ever-growing, powerful set of context-sensitive, automated refactorings. And, though test-first programming dramatically reduces the need for debugging, when we have to do it, VAJ's debugger lets us change code while debugging, saving loads of time. Nevertheless, IntelliJ is a close contender with VAJ, and I suspect that it and other commercial IDEs may soon rival VAJ as the tool of choice for XP.

Mucho Memory, Slow Execution
VAJ helps Extreme Programmers develop software efficiently, but what are its downsides? Well, the enterprise version, which gives you team-level version control, is pricey, but don't forget the cost of the time you waste by not using a powerful tool like VAJ—the same argument you'd make for a tool like jFactor). VAJ also hogs memory, which can increase your hardware budget. VAJ isn't a speed demon at running Java. So if you need super-fast execution during development, it's time to make some choices. On one Extreme Programming project, we found that our tests were taking nearly 40 minutes to run. Granted, we had a lot of test code, but this slow execution time was unacceptable, since it was causing a traffic jam at our integration machine. We got around this problem by optimizing our test code and by writing some VAJ code to export any changed code from our VAJ projects to the file system, where we could then run the tests under a fast JRE. That substantially improved performance.

VAJ also locks you into a certain level of the JDK, so if you need a new feature in the latest JDK release, you're out of luck. In VAJ's early days when, for instance, it didn't even support the JDK 1.1 inner classes, this was a problem, but the projects I've worked on over the past few years haven't needed features beyond those provided in JDK 1.2 (which VAJ 3.5 supports).VAJ has another bad habit: It alphabetizes your code. So if you want all of your constructors and field declarations to be at the top of your class, make sure they all start with the letter A. This is quite irritating, particularly when you export code from VAJ to share it with others.

The Eclipse Java IDE [click for larger image] An X icon appears just after the setUp() method because it is missing a semicolon. This icon is also shown in the tree view to the left—with the X being propagated all the way from the method to its class and its package. A tool tip for the runTest() method is showing.

Eclipse
Fortunately, IBM has addressed nearly all of the above shortcomings with an exciting new project and product called Eclipse ( www.eclipse.org ). Eclipse has been programmed purely in Java by Amsterdam and Phoenix, Arizona-based Object Technology International, an IBM company. Eclipse is a free, sophisticated open-source platform on which the public may create its own tools, IDEs or Eclipse plug-ins. The Eclipse Java IDE (see screen shot) is itself a set of plug-ins to the base Eclipse platform, which was designed to be language-independent. This IDE no longer locks you into any particular JDK and it includes VAJ's sophisticated version control features, but it uses popular packages like CVS or ClearCase as the version-control engine, instead of IBM's proprietary code. The OTI team has already written an excellent JUnit plug-in for Eclipse, and common refactorings, like Extract Method, are included, are undoable, and, because of the open-source nature of this project, should grow in number. Code-assist support is improved over the current VAJ, and general editing is good, though not at the level of a tool like IntelliJ's IDEA, as of this writing. Speed of the tool seems comparable to most contenders. Overall, I'm very excited about Eclipse as an Extreme Programming development tool and a successor to Visual Age. Finally, the free price tag couldn't be nicer.