Skip to main content
Jump to: navigation, search

Eclipse4/RCP/Compatibility Layer/Migration

In order to ensure a smooth migration of 3.x plug-ins running on top of a 4.x base, there are several things that need to be checked to prevent headaches further down the road.

APIs and Internals

As detailed on the limitations of the Compatibility Layer, the org.eclipse.ui.presentations API has been removed and the org.eclipse.ui.themes extension point is being ignored for some select cases. These references should be searched for to ensure that they have been refactored out into a separate bundle to prevent problems when using the original plug-in on a 4.x base.

The org.eclipse.ui.actionSets extension point has been deprecated in the 4.x stream. While they may still be used on 3.x, it is recommended to migrate code that uses the actionSets and objectContributions extension points to the Eclipse 3.3 org.eclipse.ui.menus extension point.

It should be noted that the absence of compiler errors does not indicate API-cleanliness. Interfaces marked with @noimplement may be being implemented and classes marked with @noextend may have been subclassed. Care should be taken to ensure that these API tags are being honoured.

3.x and 4.x API Comparisons

Accessing the status line

Eclipse 3.x Eclipse 4.0
IStatusLineManager statusLine;

Associating help context with a control

               viewer.getControl(), some_id)
IWorkbenchHelpSystem helpSystem;
        viewer.getControl(), some_id);

Handling errors and exceptions

try {
} catch (Exception ex) {
    IStatus status = new Status(
       IStatus.ERROR, "plugin-id",
       "Error while ...", ex);
        .handle(status, StatusManager.SHOW);
StatusReporter statusReporter;
} catch (Exception ex) {"Error while ...", ex);

Accessing preference values

IPreferenceStore store =
boolean saveBeforeBuild = store
@Inject @Preference(SAVE_BEFORE_BUILD)
boolean saveBeforeBuild;

Back to the top