RCP Best Practices – Use RCP for the right reasons

Getting started

The Eclipse Rich Client Platform is extremely powerful but it’s not for everyone. If you’re going to use it, you should understand exactly why it’s the right choice for you.

People are often initially drawn to Eclipse RCP because it supplies so much out of the box. You’ve got a workbench, perspectives, editors, views, wizards and much more to work with.

This is not a bad reason by any means, but you need to make sure that your application fits into the structure provided by the Eclipse platform. I’ve seen many teams struggle with trying to fit their application into a form that works with the RCP UI model. Having said that, RCP 4 offers much more UI flexibility and we’ll get to in a future post.

Modularity

In the end, the best reason to use Eclipse RCP is that it is not just a UI framework, it’s a modular UI framework. This is both incredibly important and pretty unique. And RCP’s close integration with OSGi makes it one of the only UI technologies to leverage modularity from the ground up.

The best uses of Eclipse RCP that I’ve seen leverage this modularity to achieve things that would be difficult if not impossible using any other platform. Here are some of the most common ways that I see teams taking advantage of the power of RCP.

Note: The following content comes from a longer post I did earlier called What is RCP (and why should I care?) You can check out that post for a more in-depth discussion of this topic.

Use case 1: Customizations

A common scenario is that you would like to deploy an application to various customers, but some of them would like customizations. Let’s take an example. What if a particular customer wants an additional option to show up in a context menu?

Think about how you would do that with the technology you’re currently using. My guess is that you would have to create a separate branch for that customer and recompile the entire application. With RCP, you would simply create a bundle that contributes the additional menu item and the associated functionality. Ship that bundle to your customer and you’re done.

Use case 2: License management

What if you deploy your software as a set of independently licensed units? Or maybe you provide different levels of service based on licensing?

RCP makes this easy because it allows you to break up your functionality into independently deployable bundles. If a customer wants to upgrade or add a licensed unit, simply ship the additional bundles and they’ll become part of the application.

This is much different than simply shipping a new JAR to your customer. With RCP, the additional bundles will cause new menu items, editors, wizards, etc. to automatically and seamlessly show up in the base application.

Use case 3: Sharing a common workbench

In corporate environments, it’s often desirable to have a common workbench into which a variety of functional units can be deployed. The common workbench contains core functionality related to security, database access and other common services. The most notable example of this approach is the JPMorgan Chase OneBench effort.

Various units, or applications if you like, can be deployed into the workbench based on an end-users role in the organization or other criteria. The individual applications can be developed faster and with a more uniform look and feel because they are leveraging the common services provided by the workbench.

Use case 4: Deploying to both desktops and the web

An extreme form of modularity provided by RCP is the ability to completely swap out the presentation technology layer. The Rich Ajax Platform supplies a set of bundles that can be swapped into your application and the result is that the same code can run both on desktops and on the web.

Of course things are not as simple as that. There are issues such as singletons and session management to consider. But on the whole, it’s possible to reuse the majority of your code in both the desktop and web environments. And again, it’s the modularity associated with RCP that makes this possible.

Final Thoughts

There’s nothing really like Eclipse RCP, it basically allows you to create applications that are extensible in the same way that the Eclipse IDE is. If I had a penny for every time I’ve seen a project that created it’s own extensibility mechanism (usually based on some mangled usage of Class.forName()), well I’d probably have about 25 cents by now.

So if extensibility and modularity are important to you, Eclipse RCP is definitely the way to go. Make the most of it. And finally, have you been taking advantage of Eclipse RCP in ways I haven’t described here? I’d love to hear what uses you’re putting RCP to.