Volume Number: 20 (2004)
Issue Number: 3
Column Tag: Programming

Eclipse IDE

by Ruben Kleiman

The Cool Side of the Moon

In this article we'll tour the Eclipse IDE and discuss how it fits into the Macintosh architecture, focusing on development for Java. We will go beyond hype and precisely look at how Eclipse now stands on the Macintosh.

With so many excellent, even free, IDEs out there, why Eclipse? For the writer, there are three reasons. First, Eclipse is intuitive to learn and use, and just one IDE serves a wide variety of purposes--from Java, AOP, web, to C/C++ development. The investment pays good dividends.

Second, Eclipse's general architecture has created a global community of plug-in developers from whom I draw a wide variety of tools. Some research groups release plug-ins unavailable elsewhere. In a pinch, I can easily roll my own. One way to think of Eclipse is as Emacs for the User Interface generation. While Lisp is the language for extending Emacs, for Eclipse the language is the plug-in architecture and Java.

Finally, I'm addicted to Eclipse's extensive and reliable refactoring features: they have saved my overnighters for more useful work than code wrestling.

Eclipse is a robust, open-source IDE based on a general plug-in architecture. All components of Eclipse are plug-ins. The most widely used plug-in is the Java Development Toolkit (JDT). Another is the new C/C++ Development Toolkit (CDT), supporting the GNU gcc compilers, including Objective C. The Eclipse IDE runs on and has cross-platform development libraries for MacOS-Carbon, Win32-win32, Win32-CE/win32, Solaris/motif, QNX/photon, Linux/qt, Linux/motif, Linux/gtk, HPUX/motif, and AIX/motif.

Apart from the Java and C++ editors, there are plug-in editors for UML, XML (<oXygen/>), Ant, visual programming, and more. Editors can be extended and share their resources with other plug-ins. One need not re-invent the wheel to add a small but useful contribution. To write your own editor, use the Graphical Editor Framework (GEF) plug-in.

There are plug-ins for team support (CVS synchronization, including SSH2 in Eclipse 3.0), JUnit, code instrumentation (Clover), Automated Software Quality (Hyades), web application server build and deployment (e.g., for JBoss, Apache Tomcat, IBM Websphere, BEA Weblogic), a platform delivery framework (OSGi), and more. There is an Eclipse project developing end-to-end web service development plug-ins.

Naturally, there is a Plug-in Development Environment (PDE), itself a plug-in, for creating plug-ins. And, for the JDT and the Eclipse IDE, the help system has a well-documented Java Development Environment Plug-in Developer Guide and a Platform Plug-in Developer Guide, respectively.

So how is Eclipse integrated with the Mac? Eclipse uses the Carbon library via its Standard Widget Toolkit (SWT). While Swing generally implements its widgets with a combination of Java and native code, SWT maps its widgets to Carbon widgets via one-to-one C calls to the native widget APIs. When debugging, this means that when you run into a handle to a Carbon widget, you see precisely what you would expect if you were working in Objective C. By default, Eclipse obtains the Aqua look-and-feel and the best performance that Carbon can afford.

SWT emulates non-native widgets, and there is a separate SWT library for each platform. In addition, there's a shared library that glues SWT Java calls to the native API. At the lowest level, SWT maps to the Carbon Event Manager (Listing 1).

Event loop using a window. Display interacts with the Carbon event manager 
to handle the application event loop via readAndDispatch(). A Shell is a window entirely 
handled by the Carbon Window Manager: it is instantiated with the Display as its parent.

Display display = new Display ();
Shell window = new Shell(display);
window.open();
while (!window.isDisposed()) {
  if (!display.readAndDispatch())
      display.sleep();
}
display.dispose();

This is the main application thread. readAndDispatch() maps native events into SWT events. Carbon event loop timers are provided by Display methods. Listeners can be registered on any event type.

We can fork other threads for long-running tasks. Such threads can call back into the main thread, but only through an API that ensures that the interaction with the UI is safe. This is provided by Display's synchExec(Runnable) and aSynchExec(Runnable) methods; they allow the calling thread to block or not block, respectively, until the Runnable executes. For example, the forked thread may go off to zip some files for the user interface and, when done, use one of the *Exec(Runnable) methods to display a message to the user. From there on, Eclipse's user interface is based on SWT and JFace--a higher-level library providing Model-View-Controller-like access to SWT.

What about Cocoa? Cocoa and SWT are comparable frameworks, but SWT is founded on Carbon. The decision to use Carbon is arguable, but, since Carbon includes more lower-level APIs, it can provide some maneuvering room for the SWT implementors than Cocoa. There has been some work in pre-release versions of Eclipse 3.0 to support Carbon's HiView, but a higher priority of the Eclipse team seems to be to achieve a faster and more robust MacOS implementation in the near term. This, as we shall see, should be a welcome move.

How does Interface Builder fit in? Interface Builder generates code stubs suitable for Apple's Java extensions, but it generates NS* classes, not SWT or Swing classes. Since Interface Builder's output is a nib file, we could write a nib file reader in JavaCC and a generator for SWT or Swing using Carbon or Cocoa nibs. Alas, at the time of this writing, no such feature exists.

Finally: how usable is Eclipse on a Mac right now? The first version of Eclipse was released in November of 2001, but it wasn't until March 2003 that Eclipse support for the Mac started with Eclipse 2.1. There is little to complain about the Aqua look-and-feel (Figure 1). However, though on a Titanium PowerBook G4, at 667MHz and 512MB RAM, large project builds are as fast as one would expect, but tool tips and code assist are sluggish in Eclipse 2.1.2. Eclipse 2.1.2 is not up to par with its excellent performance on, e.g., Windows or Red Hat Linux. Eclipse developers are working to close this gap.

Eclipse 2.1.x+ uses JRE 1.4+, so you need MacOS 10.2+. Eclipse requires 100 MB on disk and 256 MB of system RAM. To install Eclipse, go to http://www.eclipse.org and follow the download link to a MacOS version, with care to use Safari and the latest version of StuffIt, as instructed. We'll use Eclipse version 2.1.2 in this article. To uninstall Eclipse, just throw away the whole folder.

Three tips. First, the help system is indispensable. It has clear, often illustrated, step-by-step, task-oriented instructions, tutorials, APIs, and overviews of platform and plug-in features. The key areas you should peruse are the Java Development User Guide and the Workbench User Guide. Since almost all the information you'll ever need is there, it will pay you to get acquainted with these pages.

Second, select the Help -> About Eclipse Platform menu for an overview of the Eclipse features and plug-ins installed in your system. An Eclipse feature is a group of related plug-ins.

Finally, access your global preferences settings via the Window -> Preferences menu. Explore the Workbench and Java settings, especially those for the Java source editor's code formatting and code assist, as well as the auto-generation of comments and names for files, classes, methods, fields, etc.

A View is a panel inside the Eclipse workbench window. For example, the Java Development Toolkit (JDT) plug-in and its extensions provide the following views:

• An editor view. There are editors supporting many file types (e.g., Java or AspectJ class, Ant build file, property file). Depending on your preferences, you also have access to other editors (e.g., Emacs) by clicking on a file and using the Open With... context menu. (Eclipse 3.0 early-access has an Emacs key binding option.)

• A view of the class inheritance tree (the Hierarchy View). In Eclipse 3.0 there is a Method Call view.

• The system console (the Console View).

• The "todos," error, build and other tool warnings, etc. (the Tasks View).

• The hierarchical view of all of the resources in your project (the Package Explorer View).

• An outline of a class's members and imported classes (the Outline View).

• Packages, Types and Members views that display and let you to focus on Java packages, classes, and members, respectively.

• The Synchronize view allows you to synchronize your project with a CVS repository.

• If you use the Apache Ant tool, the Ant View allows you to look at your Ant xml file's tasks in outline and run them individually, or to look at the properties of your Ant file.

• Eclipse's AspectJ IDE plug-in enhances most of the above views to support Aspect-Oriented Programming (AOP) using the AspectJ language. For example, the Outline view lets you see whether a member is advised, and by whom and how it is intercepted.

Many more views are available from free and commercial plugins. Views collaborate through the plug-in architecture. For example, the Members view's contents on which package is selected in the Packages view. Each view has a mini-toolbar, and sometimes drop-down and contextual menus, as well as tool icons. Try them out. Double-clicking on a view's mini-toolbar expands/minimizes the view.

Although you can open any of these views via the Window -> Show View menu, you will typically work with a group of views: this is where perspectives come in.

A perspective is just a group and placement of views in a window (Figure 1). The Eclipse Java Development Toolkit plug-in comes with some ready-made perspectives. You can create your custom perspectives based on existing perspectives by combining and arranging the views you want.

JDT's most useful perspectives are the so-called Java, Java Browsing, and Debug perspectives. You can open them by selecting the Window -> Open Perspective menu. You create new perspectives by adding, deleting, and dragging views around an existing perspective. When you place more than one view on the same real estate, view selection tabs appear. You can open multiple perspectives on separate windows.

Let's create a project. (If you want to learn more about what follows, review the help system's Java Development User Guide -> Getting Started -> Basic Tutorial section.)

• Open the Eclipse IDE.

• Go to File -> New -> Project... The project wizard's dialog lets you select the type of project. Select Java Project and click Next.

• Name the project EclipseApp and specify its location in disk (the default location is the workspace folder). Click Next.

• This Java Settings dialog allows you to specify the directories for the source and class files and libraries. First, make sure that you are looking at the dialog's Source tab. The default directory for sources should be EclipseApp/src. If it is not, select the EclipseApp folder icon, click Edit...and then click on the Create New Folder...button and name the folder src. Ensure that EclipseApp/build is the Default output folder at the dialog's bottom. If it is not, type it in.

• Click on the Libraries tab to set up our build path. You should see your default JRE or JDK already in it. We won't need to add any libraries besides the JDK's, so click Finish.

You should now see the EclipseApp project in the Package Explorer view of Eclipse.

In the Package Explorer select the src folder and select File -> New -> Package. In the dialog, name the package mypackage and click Finish. Now select File -> New -> Class. Fill in the form to create a class named HairyClass in mypackage. The class opens in the Java editor. Notice that the stub for the constructor is marked with a // TODO task. The latter appears in the Tasks view; double-click on a task to go to its location. You can set task preferences in Windows -> Preferences -> Task Tags.

For the final contents of this class, see Listing 2. Let's enter the public field at the top. Just type pu and enter Command-Space. The code assist feature brings up the available completions in the context. You can navigate the completions menu with the arrow keys or mouse to view Javadocs, if available, or keep typing to reduce the suggestions. Hit return to fire a highlighted completion. Type the rest of the line using autocompletion to get the hang of it. When you get to third field, type up to public Ve and use autocompletion to select Vector. Note that java.util.Vector is now in the imports list. Now delete this line, retype it without autocompletion, and save it. Saving a file recompiles the class. There should now be squiggly lines around the name Vector. When the mouse hovers over the squiggles, the error message displays. There should be an error icon on the left margin of the line: depress the mouse on it to get suggestions for fixing the problem. Double-clicking on any suggestion makes Eclipse implement it. As you've been navigating the code, you've probably tried the Outline view, or perhaps you've switched to the Java Browsing perspective or created your own. Finish up this class.

Now create a class called MyMain in the same package and, in the New Java Class dialog check the box to create a main(String[] args) stub. Enter the code in Listing 2.

HairyClass is rather, well... hairy? Select the field identifier foo and then the Refactor -> Rename... menu. Rename the field to myVector. You can use the Preview... button to inspect the cascade of changes resulting from this; e.g., in MyMain, the reference to foo has changed to myVector. What's wrong with this picture? Select the myVector field name in HairyClass and Refactor -> Encapsulate Field... In the dialog that appears, make sure that keep field reference is unchecked and click OK. If you now inspect MyMain, you should see the field access changed to a method access and myVector is now private. Now proud of HairyClass, we rename it GreatClass using the same refactoring feature by selecting the class name or the class icon in the Package Explorer. Let's go further by creating an interface for it. Select the GreatClass name and Refactor -> Extract Interface... Name the interface IGreatClass and check off all methods except setMyVector(Vector). Note that GreatClass implements IGreatClass. Now let's be silly and delete getMyVector() from GreatClass and save. An error appears at the top: click for suggestions and ask it to Add unimplemented methods. Now getMyVector() is re-instated, with a pointer to the method's Javadocs in IGreatClass. For fun, inline the execute method.

Refactoring is a subject in itself. Explore the refactoring features in Eclipse and you'll see that it is very hard to break them. You can rename or move anything, with collateral refactoring of comments and literals as well, if you want. It is fun to use the refactoring dialog's Preview... button to try lots of what-ifs with your code. For more on refactoring, see the help system's Java Development User Guide -> Tasks -> Refactoring.

Original listings of HairyClass and MyMain.

Class HairyClass

{
   public Vector foo;
   public int count;
   
   public void execute()
   {
      foo = new Vector(count);
   }
}

Class MyMain

{
   public static void main(String[] args)
   {
      HairyClass hc = new HairyClass();
      hc.count = 10;
      hc.execute();
      
      if(hc.foo.size() == 10)
         System.out.println("Hairy class, but it worked!");
   }
}

By default, the project compiles incrementally as you save files. There are also tools for generating Javadocs, JARs, adding your own "external" tools, and so on. Of course, for complex projects, the natural tools are Apache's Ant or Maven.

Eclipse has an installed Ant plug-in that provides an Ant editor, two views, and a dialog. Both views are outliners: one is used to navigate elements in the editor; the other to quickly execute any target. The Ant dialog lets you configure your build and change Ant options. Also, there's a trend to generate Ant files rather than execute black-box tools. For example, Eclipse's Javadoc generator (File -> Export -> Javadocs) will create an Ant file for you that runs Javadoc with all your settings. This lets you include the Javadoc (or any other tool's) Ant output into your main Ant.

Finally, with Eclipse's AspectJ IDE plugin, there is support for multiple build configurations, allowing you to, e.g., switch between pre-production and production time builds.

Each project can be assigned multiple configurations for launching and debugging. The debugger provides all of the basic features, including remote JVM debugging. This makes it easy to work with web application servers; and, there are IDE plugins for JBoss, Weblogic, Websphere, and Tomcat to control the server. For illustrated, step-by-step instructions for running and debugging your project, start with Help's Java Development User Guide -> Getting Started -> Basic Tutorial section.

Eclipse's JUnit plug-in helps you to set up test cases by mitigating the tedium of manually creating test classes. There are wizards to create test cases and suites, run them, create test configurations and debug them. If you are interested in this, step-by-step instructions are available in the help system's Java Development User Guide -> Getting Started -> Basic Tutorial.

To understand how well your tests cover the possible runtime cases, you can instrument your code with the Clover plug-in (http://www.thecortex.net/clover). Clover also gathers statistics to analyze your code's runtime characteristics.

Finally, Eclipse's Hyades plug-in is an ambitious project to provide a reference standard for tracing, testing and monitoring; it implements the UML2 Test standard. It includes user interfaces for profiling, testing (from test case modeling to implementation), logging, and platform-specific data collection. Hyades provides modules for cross-platform and multi-platform development. Stable versions of Hyades are available from the Eclipse website.

If you are one of those rare individuals in a development team, you'll use the Synchronize view or, for a full workbench, the CVS Repository Exploring perspective. You can get to the latter via Window -> Open Perspective -> Other... Set up and creation of projects is straightforward. Eclipse 2.x supports SSH1, and SSH2 will be supported in Eclipse 3.0 (in early release at the time of this writing).

Though we've only scratched the surface of the Eclipse IDE, by now you should have an insight into Eclipse, why you might want to use it, and how it fits into the Macintosh universe. Future articles will focus on cross-platform development using Eclipse's JFace and SWT libraries, on Objective C development, and on more plug-ins.

Shavor, S., D'Anjou, J., et. al. The Java Developer's Guide to Eclipse, Addison-Wesley, 2003; 896 pp.

Gamma, E., Beck, K., Contributing to Eclipse: Principles, Patterns, and Plugins, Addison-Wesley, 2003; 320 pp.

Budinsky, F., Steinberg, D., et. al., Eclipse Modeling Framework, Addison-Wesley, 2003; 704 pp.

Gallardo, D., Burnette, E., McGovern, R., Eclipse in Action: A Guide for the Java Developer, Manning, 2003; 380pp.

Ruben Kleiman is a software architect and writer now developing an intelligent personal assistant. Formerly, he was Principal Scientist at Apple Computer, Inc., Architect at SGI, and Member of Technical Staff in AI at Mitre Corporation and the Microelectronics and Computer Technology Corporation. He has lectured on artificial intelligence and object-oriented systems, holds various patents, and has written for technical journals and popular magazines. Ruben lives in Northern California and he may be reached at ruben@rubenkleiman.com.