AddThis Social Bookmark Button

Listen Print Discuss
Mac OS X > Excerpts >

A Look at the Eclipse IDE

by Philippe Mougin
11/14/2003

During the ECOOP 2003 Conference in late July 2003, André Weinand from the Eclipse development team discussed this IDE for Mac OS X. In case you're not familiar with the project, I've started with some introductory information about Eclipse before getting to the notes I took during André Weinand's presentation.

You haven't heard of ECOOP conference either? Well, let's just say that each year the European Conference on Object Oriented Programming gathers hundreds of specialists from the academic and industrial worlds for the most important European event in the field. As a very technical, forward-looking and selective gathering, ECOOP can be described as the European equivalent of the OOPSLA conference (although on a slightly smaller scale). ECOOP 2004 will be held in Oslo.

Introduction to Eclipse

Related Reading

Mac OS X for Java Geeks
By Will Iverson

Eclipse is an open source integrated development environment. It is primarily developed by OTI (Object Technology International Inc.), an IBM company. OTI, founded by Dave Thomas, is a famous name in this industry. OTI is something like the Pixar of the object-oriented world: a legendary company still at the forefront of the technology and releasing hit after hit. No wonder that some at IBM consider the OTI acquisition to be the best technology acquisition ever made by IBM.

OTI is well known for its VisualAge line of development environments, and in particular for its VisualAge for Java IDE, which was considered by many to be the best Java development environment. Eclipse benefits from OTI's experience with VisualAge, and one will find many of the great features and concepts of VisualAge back in Eclipse.

However, Eclipse is not just a new version of VisualAge. It is a new environment developed from scratch in Java, while VisualAge for Java was written in Smalltalk. On one hand, Eclipse is somewhat less powerful, productive, and fine-tuned than VisualAge for Java. But on the other it's more open to third-party tools and environments and can be adapted more quickly to new versions of the ever-evolving Java technology.

Furthermore, by making it open source and highly extensible, OTI has built up a considerable following. The Eclipse project is now supported by a consortium of companies and organizations including big guns like Oracle, Borland, IBM, Red Hat, HP, Intel, Sybase, SAP, OMG, etc. Plugins produced by various organizations are becoming more numerous.

And, finally, Eclipse has quickly become the darling of enterprise Java developers. Thanks to its open architecture, Eclipse now looks set to extend to other circles, with commitments from many software vendors to adapt their compilers and environments (e.g., C++, Smalltalk, PHP, Fortran, Cobol, etc.) to the Eclipse platform. Thus, we may one day see an Eclipse plugin for Objective-C development.

The Eclipse environment on Mac OS X
Figure 1. The Eclipse environment on Mac OS X (click for larger image)

Mac OS X is now an officially supported platform for Eclipse. The current 2.1 version is considered "early access" but forthcoming versions are expected to be complete and fully tested. Eclipse can be downloaded at http://www.eclipse.org/downloads/index.php. It runs out of the box.

André Weinand started the Mac OS X port in December 2001 as a "spare time" project. At that time there were no Macs at OTI, and so Mr. Weinand had to use his own personal PowerBook. However, the situation has completely changed and there are plenty of Macs there now.

Interest in Eclipse for Mac OS X is growing rapidly. In January 2003, Eclipse for OS X was downloaded 1,700 times. There were 20,000 downloads in March. An informal pool at this year's WWDC suggested that Eclipse might be the leading IDE for Java development on Mac OS X.

SWT: A New GUI Layer

Eclipse is implemented on top of its own graphic and widget toolkit, which is not SWING but a new kit, developed by OTI specifically for the Eclipse project, named SWT (for Standard Widget Toolkit). This may seem surprising given the huge amount of work needed to develop and maintain such a framework. Word is that IBM found SWING to be so awful and so broken when using it on earlier developments (notably when developing the first "WebSphere Studio" tools) that they came to the conclusion they needed to build their own widget toolkit to stand a chance against their main competitor in the IDE space, i.e., Microsoft and its Visual Studio product line.

There have been lively debates about Eclipse and SWT. When Eclipse was released, SUN accused IBM of corrupting and fragmenting Java.

Today, SWT is available on multiple platforms and is implemented on top of the native graphic and widget frameworks of the underlying operating systems. On Mac OS X, OTI has implemented SWT on top of Carbon. Thus, Eclipse is a Carbon application with a native Aqua interface.

Carbon vs. Cocoa

There has been much debate about using either Carbon or Cocoa for implementing Eclipse on Mac OS X. In the end, after prototyping the two solutions, Carbon won. This might seem surprising given that Apple provides a Java interface to Cocoa that could have been used by the SWT layer to easily access Cocoa, instead of having to use JNI in order to access Carbon.

However there are several reasons supporting the choice of Carbon. First, the SWT architecture has been largely influenced by the goal of providing a great native experience on Windows. Thus, the structure of the Windows API has influenced SWT. Since Carbon (and in particular its event model) is a procedural API similar to the Windows API, it is a good fit with SWT.

Another reason is that Carbon is more low-level than Cocoa, allowing you to control every low-level detail. Cocoa, on the contrary, provides a high-level framework whose goal is to free the developer from low-level details.

Because all the implementations of SWT have to provide a high degree of common semantic and behavior at the API and run-time levels, it is important for the SWT implementor to be in total control of the underlying, native GUI platform.

In my experience, Cocoa is quite flexible and, by subclassing Cocoa classes or using the various hooks provided by the framework, we get some fine-grained control. But, for OTI, the mismatch between SWT and Cocoa was too great. As stated by Carolyn MacLeod, from OTI, in an eclipse mailing list: "The more I read about Cocoa, the more it looks like an SWT peer to me [...] As such, it is probably going to be difficult to port SWT to, because of event loop issues and other random problems that come up when you try to port on top of something that is really at the same level as you, and has already solved all of the same problems that you solved, possibly in different ways."

The OS X implementation of SWT uses native Carbon widgets. Thus, if you run Eclipse on Panther, it will automatically use the updated Aqua look and feel. Some higher-level widgets are not native but implemented by SWT itself. For instance the Text widget used for editing source code is implemented on top of lower level SWT layers.

Apple's Position on Eclipse

I asked André Weinand about Apple's position on Eclipse. According to him, Apple is happy to see a new IDE for the platform. They intend to encourage such new technology but stay neutral and not favor one third party IDE or another. Beside, Apple has its own IDE story with Xcode and the numerous associated tools. However, according to some people, it seems that, behind the scenes, IBM is trying to get Apple more involved in and supportive of Eclipse. This means that we might soon see Apple becoming a member of the Eclipse consortium and provide some help to OTI for the Mac OS X version.

The Eclipse platform is language-neutral and can, through plugins, be used to develop in various programming languages and frameworks. Some Eclipse supporters think Apple should consider using Eclipse as a basis for its IDE strategy. They point at the fact that, with extremely strong support from many actors in the industry and lots of existing plugins, an Eclipse-based environment could be better for Apple than its current closed-source and proprietary approach.

However, Apple has opted for a different strategy by putting some muscle behind its own developments tools with the arrival of Xcode. There are many good reasons for Apple to go this way. In particular, it would require years of work and uncertainty to produce an Eclipse-based environment approaching the level offered today by Xcode and tools like Interface Builder for the development of native Mac OS X applications.

However, the idea of Apple integrating Eclipse in its strategy could be interesting, as far as Java development is concerned. Clearly, if OTI succeed in shipping a version of Eclipse for Mac OS X that is as good as the Windows version, a number of Java developers on the Mac will switch to Eclipse. Indeed, the power of Eclipse for Java development is hard to match. Another potential domain where Eclipse could be used and extended by Apple is WebObjects, an application server and development environment Apple got from NeXT (WebObjects is the application server used by the Apple Store and the iTunes Music Store). There is an open source plugin for Eclipse, called WOLips, which support the development of WebObjects applications.

For more information about WebObjects, check out Josh Paul's Introduction to WebObjects.

Is Eclipse a Good IDE?

Some of the first things I noted when I started using Eclipse on Windows were the native look-and-feel and the very good responsiveness of the user interface:two uncommon achievements for a Java application. I'm also impressed by the rich feature set and great assistance provided to the developer.

For instance Eclipse has excellent code refactoring capacities (overall, better than VisualAge for Java) and a powerful hierarchical view of types. One of my favorite features is the "Scrapbook" editor, a kind of "interpreted" Java environment that lets you interactively type and execute bits of Java code. This feature was already present in VisualAge and is reminiscent of environments like BeanShell (http://www.beanshell.org).

Since Eclipse is open source, the source code for the IDE and various plugins is available. This provides a useful set of examples and starting points, especially when developing plugins.

The scrapbook allows for interactive evaluation of Java code
Figure 2. The scrapbook allows for interactive evaluation of Java code

Eclipse also suffers from a number of shortcomings. I asked Martial Doré and Vincent Lajous, respectively chief architect and CTO of Orchestra Networks and experts of Java development with Eclipse, to help me provide a critical perspective on Eclipse based on experience with big and complex Java projects.

The first thing that pops up is that Eclipse presents some challenges regarding scalability, Indeed, for Eclipse to scale well on big projects, some special attention and finetuning is required from the user. Things like customization of the graphical environment, definition of subprojects, organization of source code and resources, choice and customization of plugins have to be well thought. Without such finetuning, the Eclipse environment can slow down significantly when the code base grows.

Another thing to consider is that while Eclipse gains much of its appeal from its very open, plug-in based, architecture, such powerful extensibility comes at a price. First, the architecture is not always plug-and-play, in the sense that inter-plugins configuration conflicts sometimes happen. Second, bugs in plugins can render the whole environment brittle and are hard to track down.

Several other problems decrease the developer's productivity. First, the IDE is built around various editors and views, grouped under various perspectives in a highly configurable environment. Alas, the underlying model governing the interaction and synchronization between these elements is so complex that it is often unpredictable, counter-intuitive and bugged.

We wonder if the complexity of this model will ever allow it to work seamlessly. Furthermore, some elements in the design of the IDE can decrease programmer's productivity, as far as production of Java code is concerned. For instance, the "search" view is not handy, debugging is not well integrated with the "normal" development perspectives, and the Eclipse workbench tends to quickly become very cluttered. We also wonder whether the non-overlapping windows model, which significantly reduce the surface dedicated to source code, really represent the future of IDE user interfaces. Actually, we believe that some design principles of the Eclipse user interface could be reevaluated and improved.

According to Martial Doré, "Eclipse is a quite impressive development environment. However, the ergonomics have such a degree of flexibility that I believe many developers may adopt 'bad habits' concerning the configuration of perspectives and views. In our team, we promote as best usage the 'all perspectives in same window' option and, for accessing Java code, the "Java Browsing" perspective in preference to 'Java' perspective."

On Mac OS X, I tested Eclipse version 2.1.1 as well as a pre-release of version 3.0. I found the Mac OS X port very promising. Most of the functionalities are there and the user interface looks relatively good, despite the fact that its design is more Windows-like than Mac-like. The biggest problem I encountered was the poor performance. The user interface is sluggish and the whole thing is too slow, even for simple things, on my 1GHz Powerbook. If the Eclipse team is able to polish the GUI and to significantly increase performance, I think Eclipse on Mac OS X will be a great hit.

eclipse provides a powerful debugger
Figure 3. Eclipse provides a powerful debugger (click for larger image)

In my experience of development in Java, I found Eclipse to be one of the best IDEs out there. Actually, the only IDE I know of that is clearly better than Eclipse is IntelliJ IDEA from JetBrains (http://www.intellij.com). Eclipse, which is free, is quickly becoming the tool of choice of many software engineers for Java development on Windows. For Java development on Mac OS X, I would wait for the performance to be improved before using Eclipse.

Eclipse or WSAD?

Since Eclipse does not provide J2EE development plugins, enterprise application developers find themselves obliged to enrich their environments with plugins carefully chosen from the multitude available on the market. The useful site http://eclipse-plugins.2y.net gives an overview of the most popular ones.

WSAD (WebSphere Studio Application Developer) is a commercial development environment from IBM. WSAD is based on Eclipse and contains a number of plugins for developing enterprise applications in Java (at present, WSAD only runs on Windows and Linux). For example, there is a J2EE perspective featuring editors (JSP, XML, etc.), views for connecting to data sources, and views for configuring application server deployment.

I asked my friend Nicolas André, a software architect at Infhotep, for his opinion on WSAD. He believes that WSAD is a more professional, integrated, directly operational environment for J2EE development than Eclipse. But in practice, WSAD suffers from plugin overload, which makes it consume a lot of resources.

Several plugins are loaded by default to cover all development profiles (Web developer, XML development, J2EE development, etc.), even though most of the time, a developer will only use a small proportion of the plugins provided. One solution is to "slim down" WSAD by getting rid of the unused plugins, but this operation quickly becomes complex and fiddly, particularly when changing versions.

Instead, Nicolas recommends starting with a basic Eclipse environment and adding the necessary plugins rather than reducing the unused functions of WSAD. This approach is made easier by the growing number of high-quality open source plugins.

The Next Eclipse

In the future (with Eclipse 3.0), SWT may directly use the new HIView Carbon framework. HIView, which is part of HIToolbox, is a new C-based "object-oriented" kit included in Carbon for implementing and dealing with Carbon control elements.

According to Apple, it is a modern superset of the older Control Manager API and is destined, over time, to completely replace the Control Manager. The old Control Manager function calls are now layered on top of the HIView system.

Eclipse 3.0 is also expected to better integrate with Mac OS X. This includes solving the various Aqua HI issues found in the current version and leveraging Mac OS X technologies like Keychain, Help system, Services and file system notifications. 3.0 should also bring some (much needed) improvements in UI responsiveness on OS X.

The user experience is expected to see functional improvements with a more scalable UI for big projects, with support for roles and distinction between novice and advanced functions. Tools dedicated to Java development will provide better code navigation capabilities, code folding in the editor and more refactoring capacities.

Finally, IBM might start to promote the various underlying frameworks it has built Eclipse on, like SWT and JFace, as general purpose frameworks for the development of Java applications. This probably won't make SUN very happy but might improve the situation for developers of desktop Java applications.

The Eclipse team is looking for contributors to the project. "Eclipse needs you!" stated André. There are many things to do, so if you are interested, you should contact them.

Philippe Mougin specializes in object-oriented technologies and enterprise systems. He is the creator of F-Script, an open-source object-oriented scripting language for Cocoa.

Return to the Mac DevCenter