Beginning Eclipse for Advanced Developers
I have been using emacs since 1992 - not a very long time by some standards, but I have been using it almost exclusively. When I wanted to edit a file, emacs was the tool of choice, and when it came to developing programs, emacs the only tool.
This is not to say that this approach did not have limitations, and they have been becoming clearer over the years. Emacs offers little help when negotiating a complex project consisting of a large number of files distributed over an extended directory hierarchy. Its integration with the other standard tools, such as debuggers, build scripts, and configuration management tools, always struck me as a kludge. And some attempts to bring the wonders of a graphical environment to emacs (such as speedbar), although admirable, only demonstrate that there got to be a better way!
(On the other hand, emacs is the only tool that allows you to edit a multi-megabyte binary file if you have to, for instance to repair a corrupted MS Word doc. And yes, I have done that.)
I had downloaded eclipse before, but in the absence of a
compelling reason to use it, the large number of options, menu
items, and commands simply overwhelmed me. Two things made me
give eclipse another shot: a fairly large (over 1000 classes)
and very chaotic legacy project, which I was to
maintain, and the news that (as of Milestone Build 4) eclipse no
longer requires the project files to reside in eclipse's own
In this paper, I would like to describe my experience with eclipse over the last few months, both good and bad. The primary audience I have in mind are developers like me who have not used an integrated environment like eclipse before, and wonder where to start.
For reference purposes: most of my work with eclipse was done with the Milestone Builds 4 and 5 (M4, M5), and the Integration Build I20030129, on an 800MHz Athlon machine, with 1 GB of RAM, running SuSE Linux 8.1.
I have tried both the Motif- as well as the GTK-version of eclipse. Of course this is purely a matter of personal taste, but the GTK-version strikes me as very clean and professional looking. I use it exclusively.
The GUI: Perspectives and Views
Eclipse opens up to the standard three-panel layout, familiar from most other integrated development environments (IDEs). The large upper-right-hand window is the editor, sitting on top a task- or console-window in the lower-right-hand. On the left there is a tall but narrow window to explore tree-representations of file- or class- hierarchies. All this is standard.
Eclipse refers to all these windows (with the exception of the editor window) as "views", and a group of views together with an editor displayed simultaneously form a "perspective". There are several perspectives for different tasks, such as resource (i.e. file) browsing, Java editing, Java browsing, CVS integration, debugging, as well as some others.
Views can be rearranged in a variety of ways in a perspective - they can be stacked, with tabs representing the currently hidden ones; on Windows (and only on Windows), views can be "torn off" and made to float as separate windows. An interesting notion are "fast views" - a concept familiar from most window managers. A fast view is essentially a window minimized to an icon on the workspace border (most window managers would put them at the bottom, eclipse puts them on the left hand side). Clicking the icon pops the window (or view) up, the second click minimizes it again.
We discover here what I consider a characteristic of eclipse's GUI
throughout: the user interface is very rich, but often unclear in
its semantics. For instance, a view that has been torn off can
be "stacked" on top of another, leading to a tabbed window, or
"docked" at the sides, top or bottom, leading to a split
window. The mouse pointer for "docking" is a fat arrow, pointing
towards the docking target, and does not evoke the idea of a
window split in half at all. Similarly, there is a multitude of
color-coded little icons to signify
The responsiveness of the GUI is for the most part very good, except for the tree view widgets, which always seem to respond with a microsecond delay - not really disruptive, but subliminally annoying. Worse is the occasional unresponsiveness of the editor, lasting for anything between one and five seconds. Changing perspectives always takes a second or two, and occasionally the entire application develops "screaming JVM" syndrome - a seemingly innocous user interaction leading to several seconds (up to half a minute) of almost total unresponsiveness, with the CPU load rising to 100 percent. It should be emphasized, however, that every time this happened, the application eventually continued normally again without crashes or workspace corruption.
Must have: Tasks and Java-Aware Searching
Working with eclipse is often a curious mix of joy and disappointment. However, several things about eclipse stand out so much that they quickly became personal "must-haves", all frustration with the tool otherwise not withstanding. My two absolute favorites are Tasks and Java-aware searching.
Tasks are eclipse's equivalent of yellow sticky notes - only that you don't have to stick them to your monitor, but you can stick them to a certain location in a source file (or any other file, too, of course). All tasks show up in a special window (or "view"), the contents of which can be sorted and filtered in a variety of ways. If the file is edited, the task marker sticks with the line that it was originally attached to. Clicking a task in the task view brings up the file at the line that the task is attached to.
I can't express how useful this has been to me. No more dead-tree clipboards
with outstanding features, no more grepping for
If only. Unfortunately, the disappointments are not far off. First off, tasks are not automatically grouped by project, and I can't group tasks in folders. There is no built-in way to save a list of tasks to disk (although there is a contributed plugin, which sort of does this), and eclipse has its own way of adding tasks to the list as it sees fit (compiler errors usefully do become tasks, certain CVS messages however also show up in the task list, cluttering the display). Finally, the association of tasks with files gets lost under certain circumstances (when the file is modified outside of eclipse, I think).
There are no such misgivings around my other personal must-have: Java-aware searching. Of course, eclipse offers standard file based text searches. However, it also allows searches that take into account the full context of the Java language. For each package, type, method, or field, one can search for its declaration or a reference to it.
This is an incredibly powerful feature. Imagine you might want to
replace all calls to a
Apart from its immediate usefulness, this feature is also very interesting from a more conceptual point of view. Programming has always meant editing files - with very little of the functionality of the compiler (such as awareness of types, scopes, and context) available to the developer interactively in real time. Modern tools have been slowly starting to change this and are now (finally) coming to the Unix platform.
The actual editor found as part of an IDE is often a bit
disappointing, and eclipse's is no particular exception. It's
fine and works well enough, though it can be a bit sluggish at
times, occasionally even being unresponsive for two to five
seconds at a time. The editor comes with two sets of key
bindings for most editing tasks: its own "native" one, and an
"emacs compatibility" mode. The latter can be a bit misleading,
since some emacs features (such as Rectangles or
On the other hand, the environment provides several advanced interactive features. Code is syntax checked as it is entered and flagged in real-time if it is not correct. Also flagged are unresolved type and variable names, as they are being entered. This is sometimes a bit weird, since all code is temporarily wrong while it is being typed - maybe it would it be better if code was only syntax checked once the cursor leaves the current line.
Possibly the most impact on one's work however has the code
completion facility. Hitting control-space (or
Code assist changes the way one works drastically. Was it
Relying on code assist (and one quickly comes to rely on it!)
sometimes leads to curious side effects: in the legacy application
mentioned above, a field had been misspelled (
I am deeply ambivalent on the entire topic: on the one hand, it can be argued that code completion and the like free the developer from worrying about "non-essential" details, and help to focus more on code quality and design issues. On the other hand, the occasional trip to the reference forced the mind to disentangle itself from what it was doing and encouraged reflection and a broadening of the horizon. In the absence of hard data, I believe the jury is still out on how tools such as eclipse affect other code quality metrics, such as maintainability. (Another example from the before-mentioned legacy application: because integrated tools made navigation so easy, classes were distributed quite arbitrarily over the packages, leading to an almost complete breakdown of any kind of semantic grouping.)
Eclipse offers a large number of minor features, which can help
to make a developer's life a bit more pleasant - or the
opposite, if the default behaviour is not compatible with one's
own working habits. A mandatory step is therefore to
familiarize oneself with the vast set of configurable
preferences (under Window -> Preferences). The
preferences cover things like appearance and file associations,
code formatting and syntax highlighting,
A typical example for the kind of feature one might ecounter is eclipse's "build-on-save" behaviour: when saving a changed file, this file is automatically rebuilt. Usually, this is exactly what one wants, saving a separate compilation step and providing a sense of incremental compilation. It is quite disturbing, however, when setting up new projects or workspaces, or performing some other task in which many files are being touched (because of the large number of files that need to be recompiled at each step). Of course, the "build-on-save" feature can be turned off - if one only knows where (Hint: Window -> Preferences -> Workbench).
Some features are particularly helpful for dealing with large projects. One is the notion of a "Working Set": a subset of all folders in a project's workspace can be selected, and actions such as searching and navigation are then limited to this selection. It is possible to define and maintain several working sets simultaneously, providing different simpler views of and into a large project. Similarly, when navigating the tree representation of the file hierarchy, it is possible to step "into" any folder, thus hiding the top level of the hierarchy from view: helpful for deeply nested file structures.
Eclipse is also of help when it comes to building a project.
When setting up a new project, one specifies source and build
directories (it is here that one can now link a selected folder
to an arbitrary directory on disk: Add Folder -> Advanced),
as well as any additional JARs that are required, and is good to
go. This is good enough even for fairly complex projects, without
having to resort to ant (which also can be integrated into eclipse,
of course). When compiling a source file, eclipse will automatically
add any required
Possibly the most important comfort eclipse provides, however, is its stability - in several months of rather intense work, I did not encounter a single system crash or freeze, no workspace corruption of file losses, or other tool-induced mishaps. Moreover, eclipse has proven uncommonly forgiving: interrupting some massive task (such as a complete project rebuild or an all-out text search) in mid-stream does not lead to problems, rather, the environment cleans up properly, leaving both the files in the workspace, as well as the opened eclipse window, in a good and fully usable state.
In working with eclipse, of course there were a number of disappointments. As mentioned above, my biggest gripe is the often unclear semantics of many of the GUI elements, in particular when it comes to the tree/hierarchy viewers (typically arranged on the left-hand side). All these squares, circles, triangles, diamonds, and letters; in red, green, yellow, and blue; sometimes open, sometimes filled; now next to one another, now vertically stacked, utterly fail to convey the meaning of the Java construct they are meant to represent.
The purpose and representation of some of the views could also be made clearer. For instance, there is a file hierarchy "Navigator" and a package hierarchy "Explorer". Because of the close correspondence of Java packages to the filesystem, these views are easy to confuse, leading to frustrations, because some context sensitive features one expects are all of a sudden not available: Open Type (i.e. Inheritance) Hierarchy is only available in the package view, not in the file view. On the other hand, the Working Set feature, which is so useful in the file viewer appears to be really flaky when used in the package explorer, etc.
Lastly, when going from one view to the next (and even more so, when going from one perspective to the next) the current working context is often not preserved, so that one finds oneself wondering what file (or class) one is currently looking at. It seems that other IDEs have solved these problems in better ways. (On the other hand, the package explorer allows one to browse the contents of JAR-files containing only compiled Java classes, without source. Very cool!)
Eclipse is of course primarily a Java development environment, and therefore other file types (such as XML) are not as closely integrated, in particular when it comes to features such as syntax checking, code completion, and smart searching. It is here where eclipse's plugin architecture holds particular promise: a number of plugins are available for other languages (C/C++, Python, Ruby, PHP, JSP, XML, etc.). The only support for GUI-building using eclipse is also via contributed plugins.
The foregoing presents a brief and very subjective description of my experience with using eclipse. Of course, there are exciting and important aspects of eclipse which I have not even touched upon, such as integration with CVS and JUnit, built-in support for refactoring and debugging, not to mention the vast selection of plugins (about 230 at last count), which would warrant articles by themselves.
Despite the disappointments, in particular around details of the GUI, but also concerning some immaturity inevitable in a product under such active development, eclipse has quickly proven addictive. To what degree this is so became apparent recently when I did a small (only couple of classes, really) project, and decided to do it the old-fashioned way, using emacs and little else. What a pain this was! Once used to the features provided and the resulting style of work, the benefits of using a tool such as eclipse do not only manifest themselves on large and complex projects, but even on the smallest of personal developments.
Eclipse's occasional awkwardness is more than compensated by its noteworthy stability and reliability (in a sense, eclipse is exactly what one would expect from IBM: complex and sometimes clumsy, but above all reliable!), but in particular by its extensibility and the community momentum it has been able to attract. At OOPSLA 2002, rumours could be heard that Kent Beck and Erich Gamma were working on a book about eclipse - clearly, eclipse is an extremely (!) interesting tool.