Eclipse RCP and desktop Java - are we there yet?

I’m currently working on an Eclipse RCP project, which is supposed to be mostly used by non-technical people. Actually in my company today, Eclipse RCP is the de facto technology for building all desktop applications - from developer workbench to everyday necessities. There are RCPs built for programmers, testers, and everyone else. It looks like Eclipse RCP is hitting its prime time. But, is it?

Eclipse RCP, since it was first introduced with Eclipse 3.0 back in 2004, has come a long way through 3 whole years of evolution. With RCP, the Eclipse technology is becoming ubiquitous, rather than merely a development environment. From a developer’s perspective, it’s really a great technology. It virtually saved Java in the desktop battle. It’s well architected, standardized, robust, incredibly powerful to be extended, and like all Java applications, it runs on most platforms.

But with the wider acceptance of RCP and developers going great lengths to exploit its extendability, its shortcomings are being more and more exposed. To name a few, performance and user experience.

To take an example, the next major release of Lotus Notes, release 8, is completely built with Eclipse RCP. Despite its fantastic features, beta testers are unanimously complaining about its sluggish performance and lack of stability. Notes 8 is just going GA today. It’ll be interesting to see how the first batch of end users say about the next generation monster RCP that’s supposed to be lived with on a daily basis.

Another example is Lotus Sametime 7.5. I’ve been using it for quite a while now. Though I love to write interesting plugins for it, I can’t deny that the 3 minute plus load time (on my previous old Thinkpad T41 laptop) I sit through every time I launch Sametime is nothing but like killing myself slowly. It’s a nightmare. Anyway, it’s a chat program, isn’t it?

Another big issue is the very existence of RCP applications on client desktops. First, to run an RCP, you need a JRE, of course. That’s 70 megs for Sun JRE 5.0. Then, various JRE quirks drive developers nuts and some larger RCPs come shipped with bundled JREs in the packages. That’s an extra tens of megs added to the package. Then that’s the RCP platform itself which is over 10 megs. So even without any useful code, the prerequisites account for more than 100 megs!

Today, Rational ships most of the super mega RCP products on earth. A complete Rational Software Architect bundle comes with more than a handful of DVDs. That’s even more than many of the super cool PC games today!

Imagine that you need to run a bunch of RCP desktops at the same time. Each one consumes several hundred megs of your precious memory. More than a few of them refuse to use your system JRE and stick with their own shipped instance. So you even have more than a few JREs running simultaneously. That’s not a happy future definitely.

So what’s wrong with today’s Eclipse RCP? What’s the cure? I’m thinking about a few.

First, great platforms can’t cook the dinner for you! It’s still the developers’ responsibility to control the RCP’s performance and usability! Take great efforts to cut down unnecessary weights. Pay extreme attention to avoid memory leaks. There’s no magic in it!

Second, the consumer JRE is really a late comer. But better late than never. Today the desktop RIA war has already begun. Consumer desktops are being invaded with a bunch of runtimes. JRE, one of the oldest runtimes, really needs to get itself lean to have a chance. Sorry, but 70 megs of installation is simply insane.

Third, great tools can be bad if you put it to the wrong use. Eclipse RCP can build anything. That’s right. But does it have to?

I’m kind of concerned with what the 2007 Eclipse Roadmap has put it for RCP. IMHO, it’s definitely not more functionality, or frameworks that RCP lacks today. There’s still lots of work to do to make RCP and Java desktop truly usable for everyone.