Confessions of an Eclipse convert

by Tom Tromey

As a long-time Emacs™ user, and a typical command-line-oriented UNIX® person, I was skeptical when I first heard about Eclipse™[1], an extensible open source integrated development environment. Even when I was working[2] to make Eclipse run when compiled with GNU gcj[3], I used it primarily as a smoke test for the compiler and GNU Classpath[4] libraries.

However, I saw quite a bit of Eclipse, and I frequently heard it described as the premiere open source integrated development environment, especially for Java. So, seeing that I work on GNU Classpath, which is mostly written in Java, I decided that I would give it a serious try.

The best way I could think of to do this was an experiment: for two weeks, do all of my Classpath work in Eclipse. (Naturally I wasn't so rash as to shut down Emacs--after all, that is where I read my email.)

Set up

I won't bore you with all the details of setting up GNU Classpath so that it would build properly in Eclipse. Because Eclipse is reasonably flexible, we were able to make it work. However, because none of the Classpath hackers were Eclipse experts when we started, it did take a while to iron out the problems. (This is to be expected when integrating any project's existing build setup into an IDE. The process is much simpler if you are starting fresh.)

The result works quite nicely. First, parts of Classpath's autoconf-based build are run. This is needed because some Java source files in Classpath are built by 'make.' For most of the build, however, we rely on Eclipse's internal Java builder; the benefits of this will be discussed shortly. Following this, the native code in Classpath is then built, again using 'make.'

Developers today can simply check out Classpath and have a completed build in minutes[5].

The first observations

My experiment began with a plain Classpath build, which let me explore the basic functionality of Eclipse, both general and Java-related.

The most interesting aspect of this, for me, was that by using the built-in Java builder in Eclipse, we got to take advantage of Eclipse's excellent built-in compiler. What I found here surprised me: Eclipse's compiler is not only quite fast--it can build the one million lines of Classpath in under a minute while remaining incremental.-- This function means that many compilations are complete and the results ready to be run as soon as I've saved my changes. This is not just cool, but also supremely practical, as it eliminates one of the main causes of waiting (and thus loss of mental flow) while programming.

The compiler also builds an internal model of your Java program and uses this model to support refactorings. Many different refactorings are supported; a simple example is that Eclipse can change the name of a program entity (field, class, package, etc.) and update all its users without accidentally updating a part of your program that uses the same name but actually refers to something else.

This model also lets Eclipse provide a number of features which rely on knowledge of your program. So, for instance, you can change a class to implement an interface and have Eclipse provide stub implementations of all the newly-inherited abstract methods. Or, for daily use, things like completion are completely context-sensitive. For instance, when trying to complete the name of a method in an invocation, Eclipse will only offer names which are actually methods available in the qualifying type.

Daily tasks

The Eclipse SDK has some awesome technology in it. But how useful is it on a daily basis? Here I walk through some tasks frequently needed when hacking on GNU Classpath.

Editing.

Although it has "Emacs" key bindings, they are not nearly complete nor faithful enough to fool a longtime Emacs user; and a week certainly was not enough time to fully acclimate. Some functionality is simply missing--for example, I couldn't find a way to insert the contents of an arbitrary text file into the current editor.

That said, the Java editor in Eclipse knows a lot about Java. It highlights sources according to syntax; hovering over an element will bring up its javadoc in a tooltip; it can selectively collapse or expand elements based on the structure of the code. (For instance, you can hide the body of a method, showing only the declaration.) Eclipse also provides a cool "Quick Fix" feature. The idea here is that Eclipse knows canned fixes for certain simple bugs and, you can simply click on the error and immediately fix the problem without typing at all.

CVS operations.

Eclipse's CVS support is quite convenient. Making patches (a necessary daily task for me, due to the GNU Classpath development processes) is simple, as is committing and updating.

In particular I've found updating my working copy to be nicer than the command-line experience, as Eclipse will also immediately do a build. This reduces the amount of typing (and waiting) I have to do.

With Eclipse it is also very difficult to forget to "cvs add" a new file, as by default it does this automatically before a commit.

Building.

When using Eclipse I no longer really think about how Classpath is built. There's simply no reason to think about it; it happens automatically, and usually invisibly. The build, in the sense of the Eclipse-specific configuration required to compile Classpath, breaks rarely.

Eclipse's compiler has one other unusual feature: it will still generate code when it encounters an error. Rather than stop entirely, compiler will emit code for the erroneous classes which will throw an exception if it is ever invoked.

At first this seemed bizarre, and indeed in a command-line world it would be a bad misfeature. However, in the context of the Eclipse GUI, it turns out to be indispensable. What it means is, if someone checks in bad code (which, while against Classpath policy, nevertheless does happen from time to time), and this code is in an area other than the one I'm working on (which is the norm), then I can simply ignore the errors and go about my work. (This works for me because Classpath is very large, and my work doesn't often overlap with that of other people. For smaller projects this is more likely to be an unavoidable problem.)

Because Eclipse automatically flags errors as you type, it is very hard to check in a build-breaking syntax error; most build breakages in GNU Classpath now come from developers who do not use Eclipse.

Testing.

GNU Classpath contains only the class library--it does not have a virtual machine, and thus can't be run in isolation. So, as part of the experiment, we set up a couple of VMs to build in Eclipse. The idea here was simple: make it possible to check out and build a VM, and have it use the copy of Classpath that Eclipse created. This way, changes in Classpath ought to be available instantly for testing.

Implementing this feature required some tweaks to Classpath and the two VMs we converted to this approach (JamVM and Cacao). However, now that this work has been done, a new Classpath developer can simply check out the VM and a couple of other projects and have a full, working Classpath development, runtime, and testing environment very quickly.

Classpath's sister project for testing the class libraries, Mauve[6], is also readily checked out. Mauve comes with a built-in Eclipse launcher which makes running a given test case a single-click operation. This means that iteratively running a patch against a failing test is very simple.

Debugging.

Debugging is fairly weak at the moment, as none of the free VMs currently implement the necessary debugging protocol (this is being worked on). However, as recompilation is so fast, I find that, in the meantime, simply adding print statements to the Classpath code works reasonably well.

Downsides

Eclipse is not a panacea, and, despite the marketing, it also isn't a universal tool. It still has shortcomings compared to the traditional UNIX environment.

In addition to the editor's problems, scripting in Eclipse is nonexistent. On occasion in Emacs I will write some Lisp code for a particular task; the one time this occurred with Eclipse I wrote a program externally and used it instead.

Eclipse uses a lot of memory, partly because it is enormous, and partly because it does keep a model of your entire program in memory. It runs comfortably on my 1G machine--but was sluggish when I had 512M. (Remember when we thought Emacs was huge?)

The Eclipse GUI is a bit strange and could benefit from the attentions of a GUI designer. Some things like adding builders or importing existing projects are a bit idiosyncratic. Also, Eclipse more or less assumes that projects have a single implementation language. So, for instance, we treat Classpath as a "Java" project, even though it includes a fair amount of C code.

Long-term use

Since my experiment, I've done all of my Classpath hacking in Eclipse. I think that my general productivity has risen as a result of this switch, the mark of a good tool. In particular, I find that Eclipse has removed much of the drudgery of daily development--waiting, futzing with build scripts, and writing boilerplate.

Wishes

Eclipse isn't perfect for Classpath development. There are a number of problems we've discovered which we would like to have resolved. Also, Eclipse doesn't really handle native methods in Java code at all right now; this area could use a major overhaul.

I've also noticed that moving from developing Java in Eclipse back to developing C or C++ in Emacs is fairly painful. The C/C++ tools are ripe for improvement, following the model laid out by Java: incremental compilation, incremental linking, eliminating waiting during development.

About the author

Tom Tromey is an engineer working on gcj at Red Hat. He has worked on many free software projects over the years, and co-wrote GNU Autoconf, Automake, and Libtool.

References

[1] http://www.eclipse.org
[2] http://lwn.net/Articles/43096/
[3] http://gcc.gnu.org/java/
[4] http://www.classpath.org/
[5] http://developer.classpath.org/mediation/ClasspathHackingWithEclipse
[6] http://www.sourceware.org/mauve/