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:

eventBroker.send(UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC,
UIEvents.ALL_ELEMENT_ID);

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.

Localization

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 this blog post 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)

to

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.

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.

Conclusion

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.