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

So what is RCP specifically? The first thing to understand is that RCP is not a single framework, but a collection of lower-level frameworks. Most technologies rely on other lower-level technologies, and RCP is no different. Specifically, RCP leverages:
- 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 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.
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.


Very interesting article. Helped me look at RCP from a different point of view.
Thank you for this useful RCP overview. It sheds some light on what RCP is all about.
Maybe it would worth mention something about Extention Points mechanism. It is a mechanims very used in Eclipse Plugins and RCP development.
Thank you, jtonic
i’m a brazilian developer, and i’ve been using RCP for over a year and all i can say is: AWESOME! i can’t think anything else when developing for desktop
Great article.
Have you considered writing an update on your “Eclipse and the modular convergence” post? It’s been a few years – and I would be interested to hear what you think of the present situation of OSGi and such.
Has OSGi gained as much popularity as you thought it would? Have the tools improved? Have the technologies converged or diverged?
Enjoy your posts, alas there are too few of them.
Thanks,
@drozzy That’s a great idea and I’ll try to write an update soon. The short answer is that things are moving but very slowly. In my opinion the general problem is that it’s still too hard to get started with OSGi. The causes are varied, but tooling and documentation are two of the main factors.
Anyway, thanks for the kind words, and I’ll try to write more often :-)
— Patrick