Eclipse RCP Rant

After about a year of learning and using Eclipse RCP (herein referred to as "RCP") I figured that it takes an average Java developer roughly 6 to 8 months of experience to become reasonably proficient in its APIs.  Of course, this figure heavily depends on previous experience (e.g., familiarity with native UI APIs, or Swing, or none at all) and will vary from person to person.

It has been roughly 5 or 6 years since I've started using Eclipse as an IDE, and 3 or 4 since I starting using RCP heavily.  Recently I've been exposed to both in a Linux environment which has made me see how difficult it is to use RCP as a cross-platform framework and reflect on many of its weaknesses.  Now I need to rant about it.


Use it how it was intended to be used, not how you want to use it.

SWT was inspired by the need to have a fast UI API with widgets that don't look like cartoons and feel awkward on every platform.

However, when it comes to look and feel, SWT can never solve the fact that an application that was primarily designed in GTK will look different than one developed in Win32 or OSX.  There is almost always something subtle, such as widget spacing or ordering, that will make these applications feel different from a native one.  Eclipse IDE/RCP is no different to me -- it always feels like Eclipse, never embracing the core concepts of each platform it supports.

Look and feel is only a minor issue at the end of the day.  Users have been bombarded by countless skinned applications to the point where it's almost impossible to define a usability standard that actually improves usability.  The best that one can do is ensure that an application is consistent within itself.

At the end of the day, SWT's weakness is that it can fall apart with difficult to solve bugs when an application developed on one platform is moved to another.  While your application in Win32 may work perfectly fine, it might grind to a halt on another platform if you were pushing the boundaries of the API.

These nasty bugs happen because the designs of each UI API that SWT support have differences that make it very difficult for SWT developers to balance compatibility and usability (in terms of both API and end-user experience.)  As a result, it's difficult (or you're just not allowed) to extend SWT widgets to provide your own behavior.  Nasty bugs can show up if you happen to do something that's supported by one UI, allowed in SWT, but crashes in another UI. 

In short, if you wish to use SWT in your application, you must tread lightly if you wish to write once and run anywhere.


Don't be too specific about what you want to see.

Extension Points

Extension points are a neat way of providing a means for unrelated plug-in (or module) to contribute to the final product.

Many extensions are used in conjunction with other extension to make things happen.  For example, the commands, handlers, and menu extensions are used together to contribute items to menus, toolbars, and popup (context) menus.  There are three issues that I have with these sorts of extensions in RCP.

First, the documentation for each extension documents each extension, but are extremely light on how to connect the dots.  The handlers documentation doesn't indicate how it fits in with commands or menus.  To figure things out you will be forced to seek out tutorials and forums on the web to hopefully piece together how things are supposed to work.

Once you've figure out how to connect the dots and have contributed your own application's menu items, you'll want to take advantage of existing RCP commands and handlers

Reimplement the Wheel

Welcome to Eclipse

This is perhaps one of my biggest gripes with Eclipse.  Part of the fault of this lies upon adopting OSGi as its run-time container.  It is also partly the fault of SWT.

If you want to use it in Eclipse, it needs to be in plug-in form.  While wrapping an existing JAR is supported, this becomes a very difficult problem if you want to try to wrap a JAR that depends on JARs that you've already plug-in-ized.  The end result is that you'll probably pass over the JAR that you want to use because it will be too much effort to jig everything the way you want it to be.  It's really too bad that for the sake of RCP that RCP or OSGi doesn't support a compatibility layer for easily working with regular JAR files on your classpath.

If a project has been adopted by the Eclipse foundation, it's a way of telling you that you won't be able to easily use it outside of RCP, in a simple SWT application, for example.  Want to use GEF in your SWT-only application?  Nope, it uses portions of the platform for localization.  My impression of the attitude behind RCP is that nothing in Java's framework was done right and that it needs to be implemented the "right" way.  Unfortunately the "right" way means that you'll often run into issues using anything in RCP that's not been built for it or vice versa.