Skip to main content

Platform and Equinox API

Platform Changes

Contribute e4 Views into the IDE Native e4 views can now be contributed to the Eclipse workbench via extension point. The org.eclipse.ui.views extension point now supports an e4view element for declaring a new view for the IDE whose implementation is done in the e4 style (i.e. an annotated POJO).

new extension

The new type of extension is identical to the original 'view' except for relaxing the requirement that the 'class' implement IViewPart.

For those that are unaware of the e4 way of coding, here's what the implementation of an e4 view looks like:

import javax.annotation.PostConstruct;
import org.eclipse.e4.ui.di.Focus;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Label;

public class RealE4View {
	Label label;

	void createView(Composite parent) {
		label = new Label(parent, SWT.BORDER);	

	void setFocus() {

Note how it's a simple Java object (POJO) and how few dependencies it has; this has already proven itself as a far more convenient way to write the code and has great advantages in testing (because of its few dependencies).

CSS bridge The Eclipse 4 CSS-based styling engine has been connected to the classic Eclipse platform theme APIs through a new mechanism called the CSS bridge. This support enables a number of new user cases:
  • Accessing legacy platform Color and Font definitions from within a CSS style sheet:

  • Overriding Color and Font definitions in a CSS style sheet:

  • Adding new style definitions within your CSS that will be surfaced for user customization on the Color and Font preference page:

This bridging has a number of nice properties:
  • The legacy color theme definitions overridden or added in the CSS style sheet are merged with the current theme.
  • When switching themes, overridden values are re-merged with the new theme.
  • The new definitions added with the CSS file (the last use case) are available in the CSS theme that provides it.
Note that after switching CSS themes, the definitions can be unavailable in the theme registries when the new theme doesn't re-define it. This means when using theme definitions out of CSS files, you must be prepared for such situations and use proper default values in the case when some definitions are missing.
New 'themeAssociation' element of the 'org.eclipse.e4.ui.css.swt.theme' extension point An Eclipse platform CSS theme can now register an association with a legacy platform Color and Font theme. After defining the proper association between themes, changing themes in the Appearance preference page will automatically set the associated Color and Font theme.

Improved Recenter command Like in Emacs, the Recenter command in textual editors now cycles between center, bottom and top.
Ant 1.9.2 The platform has been updated to use the latest version of Apache Ant (1.9.2). For more information on what is new in Ant 1.9.2, see the official what's new.
Platform Ant BREE update Platform Ant has had a BREE update to require a Java 1.6 compatible execution environment (or newer).
Platform Debug BREE update Platform Debug has had a BREE update to require a Java 1.6 compatible execution environment (or newer).
New debugger examples New examples have been added to the Platform Debug git repository. The org.eclipse.debug.examples.mixedmode project demonstrates how to use Debug's mixed-mode launching support. The org.eclipse.debug.examples.memory project provides sample content to display in the Memory and Registers views.
Updated to Batik 1.7 The Platform now includes a newer version of Apache Batik, version 1.7.0. This new version is being used for CSS parsing in the declarative styling engine, and is notably faster than the previous version.
Removed WorkspaceLock API The WorkspaceLock API allowed a special client (usually Platform UI) to hook into the locking protocols used by the workspace implementation. This hook was used to mitigate deadlocks due to interaction with synchronous SWT events, and was never intended to be used by other clients. In the 3.0 release this API was deprecated in favor of a more general API provided by the bundle. Invoking this API has had no effect since the 3.0 release. The specific API being removed includes:
  • The org.eclipse.core.resources.WorkspaceLock class.
  • The method org.eclipse.core.resources.IWorkspace#setWorkspaceLock
Clients that directly use an API listed above should remove any references to it.
Removed IncrementalProjectBuilder#getRule() API The IncrementalProjectBuilder#getRule() method returned a scheduling rule that was required for building the project by the builder. This method was intended to be used by the builder framework only. In the 3.6 release this method was deprecated in favor of a more general method IncrementalProjectBuilder#getRule(int, Map). The specific API being removed includes:
  • The method org.eclipse.core.resources.IncrementalProjectBuilder#getRule()
Clients that directly call the API listed above should remove any references to it or replace them with calls to IncrementalProjectBuilder#getRule(int, Map). Clients that implement the API listed above should implement IncrementalProjectBuilder#getRule(int, Map) instead.
EMenuService released as API The EMenuService service has been released as API. RCP clients must adjust their package imports to
MLocalizable mixin interface The mechanism for localizing strings in the application model has been changed. Previously, EOperations (methods) were used to get a localized value. Now, volatile, transient, derived, unchangeable EStructuralFeatures are used. This enables notifications if a localizable value has changed. To mark EClasses who hold localizable informations and to inform them externally about a changed Locale, the MLocalizable mixin interface is introduced, which contains the single method updateLocalization(). This enables the platform to generically search the model for model elements affected by a Locale change and force them to update.
Locale change propagation A new service called ILocaleChangeService has been introduced, which supports changing Locale at runtime. Using this service will:
  1. Update the Locale in the application context.
  2. Inform all model elements of an application that implement MLocalization about the change.
  3. Post an event via event broker.
Locale change consumption There are now three ways to be informed about a Locale change:
  1. Via event broker by listening to the topic org/eclipse/e4/core/NLS/LOCALE_CHANGE
  2. Via dependency injection by getting the value for TranslationService.LOCALE injected (e.g. via method injection)
  3. Via attaching to the model events listening to the newly introduced LOCALIZED-Features
Note: The renderers need to be modified to listen to the LOCALIZED-Features, otherwise the Locale change at runtime isn't supported!
ResourceBundleProvider A new ResourceBundleProvider service has been introduced to abstract out the reference to the BundleLocalization OSGi service. This enables application authors to change how ResourceBundles should be looked up within their Eclipse application, e.g. using class-based ResourceBundles, loading translations out of a database, loading ResourceBundles from a server by using a different ResourceBundle.Control. The default implementation DefaultResourceBundleProvider is internally using BundleLocalization to keep the known default behaviour.
TranslationService update The TranslationService, that is used to localize the application model, had several downsides regarding extensibility. A lot of code needed to be copied in order to create a custom TranslationService that retrieves translations from a different location than the OSGi-ResourceBundle. To make it easier for users to implement a custom TranslationService, the API was modified. The method getResourceString(String, ResourceBundle) is moved from BundleTranslationProvider to TranslationService with protected visibility, as it contains the logic to retrieve and transform the translation key that is set in the application model. The default implementation BundleTranslationProvider is now using the ResourceBundleHelper in combination with the ResourceBundleProvider. This way the localization of the application model and the localization via new message extension are using the same mechanisms. As a small enhancement, this also enables the usage of dot separated keys for translating the application model.

As part of this work, the previously internal package has been released as API.

CSS includes CSS files for Eclipse can now include other CSS files via the @import url("platform:/plugin/Bundle-Symbolic-Name/path/file.extension"); statement. This allows easy reuse of existing style sheets.
Improved OSGi integration Eclipse implementations can retrieve the OSGI BundleContext via an extended object supplier and the @Inject @OSGiBundle annotations.
Platform code improvements During the last milestones, the platform team has invested in cleaning up the existing codes basis to simplify contributions by new and existing contributors. For more details, see bug 420779. During this update, several plug-ins have been upgraded to require Java 1.6 instead of Java 1.4 or Java 1.5.
New filesystem fragment for Java 7 API A new filesystem fragment supporting Java 7 file API has been added. The new fragment named org.eclipse.core.filesystem.java7 allows to retrieve information about files such as permissions, link targets, etc. using Java 7 API rather than native code. This enables full filesystem capabilities on platforms with no native Eclipse filesystem fragment. There are three different types of filesystems supported:
  • DOS/Windows filesystems,
  • POSIX compliant filesystems, and
  • filesystems that are neither DOS/Windows nor POSIX compliant.
The new fragment will be loaded and used automatically when you run Eclipse with JRE 7 or newer and no native filesystem fragment applicable for your operating system can be found (such as Solaris, ARM, and s390).

Equinox Changes

Equinox OSGi framework update The Equinox Framework implementation has been updated to implement the latest API OSGi R6 Framework specification. The OSGi R6 Core Framework specification (finalized in March 2014) contain enhancements in the following areas:
  • Introduction of Service Scopes to the OSGi Service Registry (RFC 195)
  • Improvements of Weaving Hooks (RFC 191)
  • Clarification of hooks on the system bundle (RFC 198)
  • Native environment namespace (RFC 188)
  • Data Transfer Objects (RFC 185)
  • Extension Bundle Activators (RFC 204)
  • Addition of FrameworkWiring.findProviders - no RFC
From an Equinox perspective these are considered incremental enhancements. A majority of the development effort during this release cycle is focused on refactoring and, in many cases, rewriting the core Equinox Framework implementation to be based on the OSGi generic dependency model.

For most consumers and developers this change should not be noticed. But, as documented in the wiki, there are four main areas of concern that the community should be aware of:

  • The Framework no longer uses the old Equinox resolver API org.eclipse.osgi.service.resolver internally to resolve bundles.
  • All Equinox Framework specific hook implementations are broken and will need to migrate.
  • Removal of old style plug-in support. A compatibility fragment is available to add the support back.
  • Removal of PlatformAdmin Service Implementation. A compatibility fragment is available to add support back.
Equinox Configuration Admin update The Equinox Configuration Admin implementation has been updated to implement the OSGi Configuration Admin Service Specification version 1.5. The previous release of Equinox Configuration Admin implemented version 1.3.
Equinox Regions update The Equinox Regions implementation has been updated to take advantage of Extension Bundle Activators (RFC 204) coming in the OSGi R6 specification. This allows Equinox Regions to insert its isolation model before the framework is launched so that proper region behavior can be established before any bundles are loaded in the framework.

The Equinox Regions has added a new namespace for sharing bundle lifecycle operations between regions. In previous versions of Equinox regions the only way to share bundle lifecycle operations across different regions was to share complete bundles which also shared all capabilities provided by the bundle. Now it is possible to use the org.eclipse.equinox.allow.bundle.lifecycle namespace to share only the bundle lifecycle operations between different regions. (see bug 418224)

Equinox Metatype update The Equinox Metatype API has been updated to add the methods to get the minimum and maximum values of an attribute definition. (see bug 416640)
Framework Trace Options The new OSGi framework implementation now supports many of the previously supported trace options and adds a few more trace options to help debug issues with the framework. The following trace options are now implemented:
Prints out timing information for bundle activation
Debug the caching of bundle headers
Prints out location service debug information
Prints out start level service debug information
Monitor persistent bundle activation
Prints out information about matching capabilities returned to the resolver and why any were filtered out
Prints out information about capabilities or resources that were filtered by resolver hooks
Prints out information about uses constraint violations
Prints out wiring information after the resolve process completes
Prints out the resolution report information
enables all resolver trace options

SWT Changes

SWT requires JRE 1.5 The SWT project has moved to Java 1.5 compliance level. SWT applications will now require JRE 1.5 or higher to run.
Added UI timing API SWT has added two new events, SWT.PreEvent and SWT.PostEvent, which are sent before and after all events and async runnables. These events can be used to measure the time spent on processing any events. This can be useful for detecting slow event listeners. Because of its pervasive effect on all events, this listener should be used with extreme caution. For an example of how this can be used, take a look at the Watchdog plugin in SWT examples.
BIDI segments support for Combo on Windows The Combo widget now supports the same SegmentListener API as Text. This allows an application to specify segment boundaries and Unicode Control Characters to use in the segment boundaries.

Snippet332 shows how to accomplish RTL override in a Combo.

JFace clients can use BidiUtils#applyBidiProcessing(...) to set pre-defined text types.

Added new API in StyledText to get text selection state StyledText.isTextSelected() can be used to quickly determine whether any text in the widget is selected or not.
Added API for sleep monitoring SWT has added two new events, SWT.Sleep and SWT.Wakeup, which are sent before the Display event loop goes into sleep and after it wakes up from sleep respectively. These events can e.g. be used to monitor the duration of sleep time in SWT applications.
Set text direction for the StyledText widget on Windows The StyledText widget now supports setting the text direction via the setTextDirection(int) API on the Windows platform. The setTextDirection (int) and getTextDirection () APIs are also added to TextLayout (implemented only on Windows currently).
GTK+ 3 used by default on Linux distributions (when installed and available) Linux builds come with GTK+ 3 support enabled by default on GTK+ 3 versions prior to 3.10, versions newer than that will fall back to GTK+ 2.x by default for maximum stability. The GTK+ 3 support can however still be enabled either by setting the environment variable SWT_GTK3 to 1 or by adding the launcher parameters --launcher.GTK_version 3.
Experimental support for WebKit2 added to the SWT Browser The SWT Browser now has preliminary support for WebKit2. To try it out, create a browser widget with style SWT.WEBKIT, and set the environment variable SWT_WEBKIT2 to 1. This is only supported with GTK+ 3.x; if GTK+ 3 is disabled the browser will fallback to WebKit1.
SWT applications will not be grouped together in the Windows taskbar by default SWT does not initialize the AppUserModelID (which is used by Windows for taskbar grouping) to "SWT" by default anymore. SWT applications which desire to be grouped together in the Windows taskbar should set an appropriate application name before creating the Display object as shown below:
		Display.setAppName("APP_NAME"); // APP_NAME will used as AppUserModelID
		Display display = new Display();

Previous     Next

Back to the top