What is RCP and why should I care?

The Eclipse Rich Client Platform (or RCP for short) is most commonly thought of as a UI framework, and many teams adopt RCP because it offers a way to quickly develop client-side applications. My goal here is to explain why RCP is much more than that. But first, let’s cover the basics.

RCP as a collection of frameworks

• OSGi – At the lowest level, all RCP applications run on top of an OSGi framework. This is extremely important and I’ll discuss why a bit later on.
• SWT – The Standard Widget Toolkit provides the primitive widgets (text controls, radio buttons, etc.) used to create RCP user interfaces. It functions much like AWT in a traditional Swing application.
• JFace – Building on top of SWT, JFace provides a variety of advanced UI functionality including wizards, preference pages, data binding and much more.
• Other Eclipse APIs – RCP relies on a host of other Eclipse frameworks that are not strictly part of RCP itself. These include the Jobs API for managing concurrency and the Commands API which provides menuing support.

RCP as a workbench

So if RCP is a collection of lower-level frameworks, does it contribute anything of it’s own? Well, yes. What RCP does is integrate these frameworks to provide a workbench into which we can contribute content. This workbench has a specific, though highly-customizable, structure which defines the places where content can be added.

A workbench defines where we can contribute menus, wizards, preferences, help content and much more. A workbench also contains perspectives, which themselves can contain editors and views. Our job as RCP developers is to create these UI elements and contribute them where we like.

RCP and modularity

If this was all RCP was it would still be very useful. But RCP is not just a UI framework, it’s a modular UI framework. This is both incredibly important and pretty unique. RCP’s close integration with OSGi makes it one of the only UI technologies to leverage modularity from the ground up. If you’re new to OSGi, I suggest reading my post on Why is OSGi important?

What RCP does with OSGi is fairly sophisticated. In short, it takes the concept of modularity and applies it to the user interface layer. Another way to put this is that RCP allows us to visually express the modularity made possible by OSGi. The power of RCP comes from its ability to dynamically assemble user interfaces from collections of OSGi bundles. In the end, an RCP user interface is defined by whatever set of bundles happen to exist at the same place at the same time. As we’ll see, this is an incredibly powerful concept.

So why should I care?

Up to this point I’ve discussed what RCP is from a technical point of view. But all technologies are cool in some way, and the real question is whether they’re useful to our customers and end-users. I’m going to go through a few use cases that illustrate the benefits of RCP, but the thing to keep in mind is that all of these benefits arise from the application of modularity to user interfaces.

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 Remote Application 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.

So I’m interested, what now?

I hope I’ve given you enough information to decide whether RCP is the right technology for you. Modular UIs are very powerful but in some cases they’re overkill. And there is a price to pay in terms of complexity and the learning curve, though the benefits are well worth it in my opinion.

If you’re looking to learn more, check out this list of RCP resources. And of course you should also consider RCP training. It really does help.