RCP Best Practices – Use the correct version of RCP

Getting started

RCP 3 or 4?

One of the hottest topics of discussion in the Eclipse world right now is when to migrate to RCP 4. A recent post by Wim Jongman argues that now is the time. I generally agree with this, and so my first suggestion here is to use RCP 4 if you can.

So what might stop you from using RCP 4?

Legacy dependencies

The biggest technical issue right now is that there are many Eclipse features which still rely on the legacy framework. So if you have a dependency on any of these features, you cannot develop against a “pure” RCP 4 platform.

Some of these features will be replaced or migrated to RCP 4 over time. Some may never make the switch. If you’re considering a move to RCP 4 you should take a serious look at all your dependencies and decide whether they can be removed or re-implemented in some way. In some cases this isn’t too difficult, but not always. Here’s a partial list of “legacy” features that I’ll try to keep updated. Please use the comments to offer corrections or additions.

Note: I hope that no one takes this list as any type of criticism. A ton of great work has gone into RCP 4 and there’s a lot of legacy code to migrate. If there’s something on this list you really need, consider migrating it and submitting a patch.

Help system (including context sensitive help)
Common Navigator Framework
Resource Explorer
Common views (Console, Log, Error, Properties, Progress)
Status line contributions
Progress display
Preferences dialog
Wizard integration (File > New, File > Import, File > Export)
Perspective shortcuts
Perspective switcher
Activities API (often used for security)
Update Manager
About window
Splash handlers
Standard Eclipse commands and default handlers
Editor framework (one to many editors with menu integration)
RAP (single-sourcing)
GEF
GMF
Graphiti
EMF Editors

Migration and mixed-mode development

The solution to legacy dependencies is an environment where RCP 3 and 4 code can happily co-exist. This so called mixed-mode platform would not only allow us to consume legacy dependencies but also make it possible to gradually migrate our existing code to the new framework.

There are a variety of options for mixing RCP 3 and RCP 4 code. Unfortunately, non of these support a true mixed-mode platform. The closest we can get to a mixed-mode solution right now is to use the e4 bridge, and I’d like to hear feedback from anyone using this.

For those interested, one roadblock to a true mixed-mode platform is the inability to add RCP 4 elements to the application model when running on the compatibility layer. Hopefully this will get resolved in Eclipse 4.3.

Compatibility layer

If you cannot make the jump to RCP 4, it’s still possible to take advantage of many RCP 4 features by running on the compatibility layer. While you won’t be able to add RCP 4 parts to the application model, you can still access contexts, style with CSS and much more. There are still some quirks with the compatibility layer (most of my clients are still running on RCP 3.8), but it’s very easy to try it out and see if it works for you.

Final Thoughts

There are two scenarios right now where a pure RCP 4 solution makes sense:

A brand new project with no legacy dependencies
A legacy project that can be completely migrated in one release cycle

If you’re not in one of these situations, my suggestion would be to continue with RCP 3 (or RCP 4 with the compatibility layer). There may be some applications that may never fully migrate to RCP 4 (the Eclipse IDE is itself a good example of this). Personally, I’m going to continue to offer RCP 3 training and I think this option will make sense for many, especially those with large investments in the the platform.

Finally, I’d really like to get your feedback here. Have you migrated to RCP 4? If so, what challenges or issues did you face? Eventually I’d like to have a whole section here devoted to RCP 4 migration and your input would help a lot