Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Eclipse4/RCP/Compatibility Layer/Migration

< Eclipse4‎ | RCP

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.

Using Eclipse 4 Features

The Eclipse 3.x Compatibility Layer is an Eclipse 4 application on its own right, however it makes many assumptions in how it uses the Eclipse 4 application model. Eclipse 4.2 does not officially support hybridization of Eclipse 3.x apps interacting with the underlying Eclipse 4 model.

Dependency Injection

IWorkbenchParts are not injected, and it can be a bit of a pain to expose injection to apps based on the E3.x APIs.

Poor Man's Injection

In Eclipse 4, the implementors of IServiceLocator are performed using the IEclipseContext. So view parts and editor parts can resolve items through the context using IWorkbenchSite#getService(XXX). For example, to obtain the IEclipseContext, you might do the following:

public class MyPart extends ViewPart {
    // ...
    void doIt() {
        IEclipseContext context = (IEclipseContext) getSite().getService(IEclipseContext.class);
    // ...

Performing Injection

You can also make and inject your own classes using the ContextInjectionFactory:

    IEclipseContext context = ...;
    Foo createdObject = ContextInjectionFactory.make(Foo.class, context);

Foo's lifecycle is now tied to the context: when the context is disposed (i.e., because the view has been disposed), the Foo instance will be destroyed too.

Back to the top