I recently attended the JSig presentation on Eclipse RCP presented by Neil Bartlet of Integility. It was somewhat of a surprise that Sun were sponsoring a talk about Eclipse; although this was a talk specifically about the runtime framework rather than the developer tools that created it.

He made some very good points and I learnt a few things about Eclipse that I hadn't known before (the nice thing about Eclipse is that you're always learning!). One of them was the OSGi console; start up Eclipse with -console, and you get a text-based console (either on the command line, or in the Eclipse console depending on whether you're launching it externally from PDE or internally). You can then see which bundles are in the system; ACTIVE means that they're running, whilst RESOLVED means they're ready to go (but haven't been brought in yet). I seem to recall that the last state was something like DISABLED, which means that it won't get launched. Neil used this to good effect, showing off an Eclipse RCP application that simulated prices of stocks with a simple buy/sell interface and a scrolling chart (JFreeChart works on SWT too, it seems). When it started up, there was no information being fed in, but by bringing up an otherwise inactive plugin a stream of fake pricing data started showing up and the application was brought to life. It's really nice how Eclipse can dynamically both enable (and disable) plugins/bundles; of course, I'd seen it in action with the Update Manager and not needing to restart the application, but it goes right down to the core.

I'm starting to appreciate the noise behind OSGi on the server side, too. It seems a natural extension of the OSGi model that Eclipse demonstrates to have the same dynamic loading (and unloading) of systems on the server side. Additionally, because the dependencies are versioned, it's possible for the server to have multiple different versions of a codebase installed concurrently, even in the same application. No more headaches about making sure that Log4J is the same across all components in a system any more ...

One of the other comments that struck a chord was that there's really two ends of the spectrum of clients; fat clients (where everything is done on the client) and thin clients (where everything is done on the server). However, neither of these solutions are particularly maintainable; even the AJAX clients (although cool) can grow to a nightmare of spaghetti code without care. Admitedly, AJAX frameworks will help to solve some of those issues, but I'm not sure what the state of play with regards to AJAX frameworks are at present. A rich client sits between these two extremes, and whilst it requires some support on the client side, it's perhaps a more maintainable solution than some others. Eclipse RCP is a good start towards this rich client framework; though the consensus was that it could certainly be easier to start writing RCP applications. Neil suggested that one could become proficient in Eclipse RCP in a few months; but it probably depends on the way that you learn, coupled with whether you're doing it in your spare time or as part of a product that must be rolled out in a few months. Either way, there's still a lot of extension points that come with the basic Eclipse system; and though often functionality can be added with a simple class implementing a simple interface and a few lines of XML, knowing which interface (or which piece of XML) is the tricky part.

Lastly, Eclipse RCP applications, by their nature, run off-line. This may not be an issue for systems in a working environment; but if you're working on a laptop or away from home, having the ability to work off-line means that you can be productive even when not connected. What's going to be interesting is seeing how such applications work in a semi-connected mode; protocols like IMAP build into the system an assumption that the user isn't always connected (and just resync on reconnection) but how can this work in the general case?

So, the conclusion of everyone present is that the Eclipse framework (whether under the term RCP or not) is going to be around for some time. It will also be seen in server-side systems, although I think it's going to take a while for other applications to move away from the classpath towards Eclipse bundles. Maven is an example of a tool that would strongly benefit from moving this way; however, at present, there's not much support for this. There is an OSGI bundle manifest creator for 1.x builds that's really quite old; there's one in development for Maven 2.0 as well. However, the generated bundle manifest still deals with classpath dependencies (using Bundle-Classpath) instead of bundle dependencies (Requires-Bundle) which means that it won't be possible for the near future to use Maven 2.0 to build bundle-specific code basis (like plugins for Eclipse) any time soon.

Stay tuned. The next few years are going to be interesting. By 2010, all UI applications are going to be based on the Eclipse framework, except for a few minor apps written in .Net.