Eclipse 4 is a new way of building Eclipse applications, and provides a number of features that make creating parts (views/editors), as well as obtaining service references and communication between parts much easier. If you are building Eclipse-based RCP applications, then there is no reason not to jump on the Eclipse 4 framework to take advantage of its features. If you are building plug-ins that will run on both Eclipse 3.x and Eclipse 4, then you have to consider backward compatibility requirements before you can make the switch. One way of supporting both is to use the workbench compatibility plug-in (which is what Eclipse 4.x uses if you download the SDK or one of the EPP packages) and continue to use the Eclipse 3.x APIs. However, this means the code cannot take advantage of the Eclipse 4.x mechanisms. Another approach is to write Eclipse 4-based plug-ins, and then wrap them in a reverse compatibility layer. Such a layer is provided in the Eclipse E4 Tools Bridge for 3.x feature, which is available from the E4 tools update site. This provides classes DIViewPart, DISaveableViewPart and DIEditorPart, which can be used to provide an adapter for an E4 part in an Eclipse 3.x view extension point.

In the next chapter, we'll look at approaches to migrate applications towards Eclipse 4 technologies, as well as some of the considerations that need to take place before migrating.