Beyond Code

There is more to Programming than programming...

Home   |   News   |   Articles   |   Resources   |   Projects   |   About

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 workspace directory, but can now reside anywhere on disk.

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 public, private, and protected members, as well as static or inherited fields and methods in the class outline view - but the semantics of the different colors and shapes is not at all clear. I could continue: there is symbol for Java packages in the package hierarchy explorer. Sometimes this symbol is colored, sometimes not. I still have not found out why.

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 // fix-me comments in the source code, no more fear of forgetting to take out some stub code before checking a file in. So simple this feature is, it has proven to be incredibly useful.

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 getParameter( String ) method on some com.mydomain.Utility class. A simple text search for the string "getParameter" is not an option - in a typical web application there will be a large number of calls to javax.servlet.ServletRequest.getParameter( String ), not to mention other classes that expose a method of the same name. With eclipse's Java search facility, it is possible to retrieve only references to the exact method (or field, etc.) one is interested in. (The target of the search can be selected in any editor window by right-mouse-click. Interestingly, this feature was broken in the M4 milestone build - the search had to be activated from the menu bar. This was fixed in later integration builds and the M5 milestone build.)

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 M-%) one has come to rely on may not be available.

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 M-/ under emacs-mode) brings up a list of possible completions, as well as the appropriate JavaDoc. Selecting from this list inserts the code at the current cursor position. (The exact behaviour of the code completion engine is configurable: cf. Window -> Preferences -> Java -> Editor -> Code Assist. This also gives a flavour of the richness and number of configurable preferences!)

Code assist changes the way one works drastically. Was it setAttribute() or addAttribute()? No need to consult the spec or the respective application class, code assist will tell us. Of course, this is a great convenience. But I am a bit concerned that, because it makes trips to the reference manual less pressing, some crucial information is lost. Does this function accept null as input or not? The signature alone won't tell us, but the manual would. (I am not very convinced about benefit of the Javadoc window popping up together with each possible completion - it is hard to read and somewhat crammed, there is another delay before it appears, and it covers up too much of the code being edited - the absence of a good, integrated JavaDoc browser is a startling mis-feature of eclipse!)

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 (COMPARTOR instead of COMPARATOR) - but because everyone had been relying on code completion functionality, the typo in the original declaration never became apparent. Does this constitute a problem? I am really not sure, but it does worry me (and it does not help much to know that eclipse makes it quite easy to find and change all references to this field). Code assist may improve programmer productivity when measured purely in terms of lines of code, but it does not necessarily improve the quality of the code.

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.)

Creature Comforts

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, CLASSPATH and compiler settings, and many more. The default eclipse set-up alone has several hundreds of individually adjustable preferences, and each plugin adds a few more. If there is something about eclipse's behaviour one just can't live with - chances are, it can be turned off! It takes a few hours to go through all the preferences, figuring out what they do, but it is time well spent. And one might want to repeat the exercise after a few weeks!

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 import statements, if there is a conflict (such as for java.util.Date and java.sql.Date) a dialog box appears, prompting the user to make a selection.

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.

Resources Version 1.2 (2003/05/19 03:13:39)

Copyright © 2002-2006 by Philipp K. Janert. All rights reserved.