Migrating Eclipse 4 Applications from Kepler to Luna

The Eclipse 4.4 release, called “Luna”, was released on 26 June 2014. Since I participated in the migration of a couple of Eclipse 4 applications to the new release, I want to share my findings and also get feedback if other users found some things I didn’t come across yet. This post is focused on the platform only and only on changes that affect native Eclipse 4 applications (not relevant for applications that run on the compatibility layer or for plugins for JDT). In general, a lot of effort has been made on stability and minor improvements, and there are no real incompatibilities. Therefore, I would recommend you migrate Eclipse 4 applications from Kepler to Luna. Thanks to the platform team for the great work!

If there is something important missing in this post, please comment or send me an email; I will then add it to this post.

Noteworthy Changes

Time-based @CanExecute (Bug 385394)

Until Eclipse 4.3, methods in handlers, annotated with @CanExecute, were executed timer-based every 400ms, which has led to performance problems. In 4.4, methods annotated with @CanExecute are called again only if an injected parameter changes in the context. If necessary, the enablement checks can be triggered manually with the following event:



The enablement of existing handlers should therefore be reviewed and tested.

Fragment Merging

In Eclipse 4.3 an issue in the process of fragment merging could potentially lead to duplicate elements. When merging a model fragment, Eclipse 4.3 checked whether a certain element is already present at the location where it would be placed. If a fragment has already been merged once, movable elements, e.g., parts, could have been moved to another location within the application model. Therefore, those elements were created again and duplicated. In Eclipse 4.4, the extension point “*workbench.model”, which allows the registration of model fragments, supports another property “apply”. This enumeration controls how fragments will be merged into the application model:

  • Always: The content of the fragment is always merged into the application model

  • Initial: The content of the fragment is only merged once

  • NotExist: The content of the fragment is merged if the elements are not present at the target location within the application model

For processors, only the values “Always” and “Initial” are available because the platform cannot simply check whether the elements created by the processor already exist.

Event Admin Dependency (Bug 412121)

In Eclipse 4.3, the bundle “org.eclipse.e4.ui.workbench.swt” has an explicit dependency to “org.eclipse.equinox.event”, which it really does depend on. In 4.4, this dependency was changed to be optional. It is therefore not automatically included in feature-based run configurations if the resolver does not consider optional dependencies. Since the event bundle provides the necessary implementation of the event broker, it has to be present at runtime. Therefore the bundle should be explicitly added to a target feature if it hasn’t previously been added.

MWizard and MDialog

Two new application model elements, MWizard and MDialog, have been added to the application model, but, so far, the platform does not provide a corresponding renderer and no service to work with them. There has been discussion about removing these elements again, so currently the usage is not recommended.


The localization service has been reworked and extended by Dirk Fauth and Tom Schindl. The application model elements are now able to react to locale switches at runtime. Therefore, the interface MLocalizable has been introduced, which is implemented by all elements with a visible string. The renderer will update the UI according to the new locale. Additionally, there are two new annotations @Message and @Translation. The @Message annotation allows you to write message classes (defining translatable strings) as POJOs using member variables instead of static fields so that they can be changed at runtime. The @Translation annotation allows you to inject message classes into the classes, which create and update the UI. Please see here for more details.

Java 6 (Bugs 428054, 430066)

Equinox changes its minimal bundle required execution environment (BREE) to Java 1.6. Therefore other bundles, such as JFace and e4 also finally switched to Java 1.6 and Java 1.5 is not supported anymore.

EMenuService (Bugs 319462)

The EMenuService interface, which was provisional API in 4.3 has been moved to a platform neutral bundle and is API now.

Old Bundle: org.eclipse.e4.ui.workbench.swt

New Bundle: org.eclipse.e4.ui.services

Therefore, all bundles using this service need to adapt their dependencies. Additionally, the signature of the following method has been adapted from

public MPopupMenu registerContextMenu(Object parent, String menuId)


public boolean registerContextMenu(Object parent, String menuId)

Instead of returning the registered pop-up menu, the registration just returns true if the registration was successful and false if it was not successful. If necessary, the MPopupMenu can be retrieved using the model service.

e4 Tools Incompatibility

Due to the removal of some model elements (Opaque* and Rendered*), the last checkpoint build of e4 tools as well as the last stable build are not compatible with the application model in Eclipse Luna. Therefore, the integration build has to be installed (later than 2014-02-28) until a new checkpoint build is available, which will happen soon.

Bug (fixing the incompatibility): 429299

Removal of Opaque* and Rendered*

The following elements, which previously were marked deprecated, have finally been removed from the application model.

Package (*=org.eclipse.e4)


Type of change






















Application Model Factories

The EMF Factories, which can currently be used to create application model elements (Bugzilla 409224), were not removed from the API as this would be an incompatible API change. However, one should still rely only on the factory method in EModelService to create application model elements.


The Eclipse Luna release improves stability, and there are no real incompatibilities to Eclipse 4.3. It is therefore recommended to migrate from Eclipse 4.3 to Eclipse 4.4. However, the update might be delayed until a checkpoint build of the compatible e4 tools is available.

Please let me know if you identify any other issues or noteworthy changes, and I will add them to this post.

If you want to learn how to migrate an existing Eclipse 3.x application or how to build an Eclipse 4 application from scratch, we do provide training and developer support for your project.

Please also see my tutorial for more details about the Eclipse 4 Application Platform.


3 Responses to “Migrating Eclipse 4 Applications from Kepler to Luna”

  1. Markus says:

    IMO the event admin dependency should ideally be modelled via OSGi R4.3′s capabilities ( http://wiki.osgi.org/wiki/Require-Capability).

  2. Christoph Keimel says:

    Thank you very much for the summary!

  3. Georg says:

    Hi Jonas,

    thank you very much for this article, it helped me quite a bit when migrating our (pure) e4 application from Luna to Kepler.
    Especially, the part regarding the changed behavior of the call to the with @canExecute() annotated method of a handler let me directly to some issues in our application that appeared after the migration.

    This leads me to my question: in your article you state “methods annotated with @CanExecute are called again only if an injected parameter changes in the context”.
    This brought me to the conclusion that I could do something like this (1):

    public void canExecute(@Active MyType myObject) {


    and this method would automatically be called when MyType in active context would change. However, this is not the case.
    Instead this method is only re-evaluated, when the value of the variables defined in IServiceConstants change (Active Part, Active Shell, Active Selection, etc.).
    I stumbled upon this within the init() method of the e4 class ToolBarManagerRenderer (org.eclipse.e4.ui.workbench.renderers.swt).
    Do I understand this correctly?

    So, what I do now is:

    public void canExecute() {


    public void onMyObjectChange(MyType myObject)

    Here, I trigger a re-evaluation of all tool items, which I think is too much. Worst case in this scenario: with a few more handlers that
    do it that way I have the same performance issue as I had with the timer-based approach – of course I am talking about a large application for
    this to happen.
    So, looking into the Eclipse code base, I saw, that it is possible to request a more fine-grained re-evaluation by stating the id of the toolitem
    whose enablement state is to be re-evaluated.

    So, I changed the aforementioned method to (2):

    public void onMyObjectChange(MyType myObject)
    eventBroker.send(UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC, “my.specific.toolitem.id”);

    Which worked perfectly for this specific toolitem, but had the side effect that ALL other toolitems were not evaluated any longer, as the internal ToolItemUpdater (which was introduced in Luna) from now on ignored all other items but the one specified. Reason for this behavior: all “itemsToCheck” are removed when they were once in the set of “orphanedToolItems” as there is only one instance of the updater, the now missing items to re-evaluate are never again added to the set of “itemsToCheck”.

    Wow, ok this comment is a bit long, but I wanted to make sure that I understand how things work with the handler evaluation (1) and that the described behavior of Eclipse (2) is not something that is intended (which I highly doubt).

    I hope you can shed some light on these two points. Thanks again for this summary and your other really helpful posts!

Leave a Reply

3 responses so far

Written by . Published in Categories: Planet Eclipse

Jul 11th, 2014

Twitter Google+