Platform and Equinox API

Platform Changes

Modeled user interface The Eclipse platform user interface is now represented internally as an EMF model. Applications can reconfigure or extend this model to arrive at very different presentations of their application with no additional coding required. Normalizing the workbench structure as a well defined model has the added benefit of making the code for the workbench itself much simpler and less error prone. Most importantly, this allows for very different workbench UI layouts, such as parts living outside of perspectives, views and editors in dialogs, and other designs not previously allowed by the older generation workbench with its rigid hand-crafted model. Having a model also allows for more advanced tool support for application designers, such as visual design tools.
Clean model structure The workbench model is separated into a number of different levels of building blocks. These are sets of related model functionality that can be used to augment the basic capabilities of the RCP model in order to enhance the UI. This allows RCP developers to choose the specific enhancements that they really need rather than having to make an either/or choice between a model that is simplistic versus one that can support the complete existing IDE UI. The categories are:
  • Menus and Toolbars: This is a fairly generic definition, suitable for directly implemented operations.
  • RCP: This is a Sash/Stack/Part containment model very much like the legacy one.
  • Commands: This is the e4 version of the Commands/Handlers/Bindings infrastructure. Use this model if you need more sophisticated operations like key bindings, retargetable commands (Undo, copy...).
  • Trim: Using these elements allows clients to add trim containers on any side of their window and populate them with ui elements.
  • Editing: This is a specific element used to gain access to the legacy editor behavior.
  • Shared Elements: These elements allow reuse of various model elements in different parts of the model. It will be used in the compatibility layer for supporting the sharing of views and editor areas between different perspectives.
Pluggable presentation engine The workbench model is now translated into concrete widgets via a generic presentation engine API. The platform includes a default presentation engine that renders the model using traditional SWT widgets, but applications can employ alternate presentation engines to render their application model using a different widget toolkit.
Widget styling with CSS The workbench now defines a pluggable styling engine that allows the appearance of widgets to be customized declaratively using Cascading Style Sheets (CSS). Widget details such as fonts, colors, borders, and icons can now be customized via application-defined CSS files. This mechanism supports changing styles on the fly while the application is running.

The Eclipse SDK 4 includes styling data to implement the new IDE look and feel, but rich client applications can employ different CSS styling to achieve a significantly different widget appearance.

Example of custom styling in contacts demo

Flexible tab rendering In the platform 3.6 release, SWT introduced API to allow a different renderer for CTabFolder to be plugged in. The workbench now uses this pluggable rendering to implement the new Eclipse 4 workbench look and feel.

Highlight of custom tab rendering

Hierarchical contexts The bundle org.eclipse.e4.core.contexts introduces the notion of hierarchical contexts via the IEclipseContext API. Contexts provide a mechanism for isolating application code from the framework, providing an abstraction through which application code can obtain objects and services from the framework. Contexts also provide a way for application code to make data and services available to other application code in a loosely coupled manner. Contexts currently support:
  • Context hierarchies. Contexts can be nested within a parent context to override services provided by their parent. This enables application code written in one context to be easily transferred to work in different contexts.
  • OSGi service lookup. Contexts can be used to obtain references to OSGi services. The context takes care of tracking dynamic service changes and cleaning up unused services when contexts are discarded.
  • Dependency injection. Values from a context can be injected into an application object. This results in injectable fields and methods in the application object being provided with values defined in the context. Injection completely removes direct dependency from application code onto the framework.
  • Storage of functions. Contexts can store functions that are evaluated lazily to obtain context values. A client retrieving values from a context may be obtaining raw values stored in the context, or the result of some function that was evaluated at the time of the context lookup.
  • Traditional change notification, and registration of data-binding style update code with a context. Each time the registered update code is run, the context tracks which context values were referenced. Subsequent changes to any of those values will result in the update code re-running. Updates and events are batched and queued to avoid superfluous notifications.
UI service lookup via contexts The workbench provides a hierarchy of service contexts that reflects the widget hierarchy of the workbench itself. Thus when a part obtains a service or data value from its context, it will correctly reflect the widget containment structure of that part. This allows parts to be reused in novel new widget layouts without requiring changes in the part's code.
javax.inject annotation support Context injection supports the annotations defined in the upcoming javax.inject package. Annotations such as @Inject and @Named can be used to describe context elements to inject. The internal injection processing has been updated to make use of these annotations, and passes the open source annotation-based injection test suite found at

As a result of this work the dependency injection implementation is available as an independent service. While the exact APIs are still under construction and will change, we expect to make the javax.inject-based dependency injection available as one of the core Eclipse 4 application platform services.

Common event bus The Eclipse workbench now has an event bus style architecture based on the publish/subscribe pattern. This means a 'one stop shopping' approach for workbench clients; any user interface event we expect a client to be interested in (UI model changes, part life-cycle events, etc) will be available through a common mechanism simply by registering an event handler against the appropriate topic.

Event bus

Git migration During this release cycle, the Eclipse and Equinox projects migrated their source control systems to Git. The new Git repositories are now available for developers to clone or fork:
Flexible viewer refactored The code driving the debug views (Debug, Variables and Breakpoints) has been substantially refactored to improve its overall quality, stability and performance.

Some of the more notable changes include:
  • There is a 30% improvement in the overall performance of the views
  • Two new interfaces have been added to the provisional API: IModelProxyFactory2 and ITreeModelViewer
  • The Copy and Find actions have been re-written to work better with the virtual views
  • A new viewer filter extension has been added to TreeModelViewerFilter, mitigating scrollbar presentation issues
The complete list of changes can be found here.
Refactored Eclipse 4 Event API Workbench UI events have been refactored to make them easier to understand and use. For a detailed write up on the Eclipse 4 event model and the changes in this release please take a look at and
Trim styling In the new window trim implementation, the drag handle and the frame surrounding the trim are defined through CSS. Here's an example of what this looks like:
.MToolControl.TrimStack {
	frame-image:  url(./winXPTSFrame.PNG);
	handle-image:  url(./winXPHandle.PNG);
	frame-cuts: 5px 1px 5px 16px;

frame-image and handle-image define the images to be used to draw the frame. The frame-cuts attribute is a set of 4 integer values that are used to divide the frame-image into specific areas by defining two widths and two heights (the third is just the image size minus the sum of the other two. This allows us to determine what part of the image to use for the top/right corner.

Here is a more interesting example that illustrates the power this gives to applications to customize their appearance:

Trim styling

CSS-based Theme changed event An OSGi EventAdmin-based event is now raised on theme change. Subscribe to the IThemeEngine.Events.THEME_CHANGED topic to be notified when the workbench theme is changed.
Changes to CSS extension points For those providing extensions for the new CSS support, the extension points for providing property handlers and element providers have been renamed to org.eclipse.e4.ui.css.core.propertyHandler and org.eclipse.e4.ui.css.core.elementProvider (respectively).
RelaunchLastAction has been made API The internal class RelaunchLastAction has been promoted to API and can be found in the org.eclipse.debug.ui.actions package.
Add new expression image constant has been made API The constant IDebugUIConstants.IMG_OBJ_ADD_NEW_EXPRESSION has been added to API to allow consumers who extend or use the Expressions view look-and-feel to use the Add New Expression icon (The add new expression icon).
Toggle breakpoints target manager has been made API The interface org.eclipse.debug.ui.actions.IToggleBreakpointsTargetManager has been made API to allow clients access to known IToggleBreakpointTargets. The new API can be accessed via org.eclipse.debug.ui.DebugUITools#getToggleBreakpointsTargetManager()
BreakpointTypesContribution has been made API The class org.eclipse.debug.ui.actions.BreakpointTypesContribution has been added to API. This class can be reused by clients to add a breakpoint type action in the editor gutter context menu to match the action(s) that appear in the Run > Breakpoint Types menu.
Find action can be customised in Variables View specialisations Consumer now have the ability to completely override the behaviour of the Find... action in the Variables View and any of its sub-classes, e.g. Expressions View, Modules View, etc.

To replace the default Find... actions clients must provide an adapter for the interface org.eclipse.debug.internal.ui.viewers.model.provisional.IViewActionProvider.

For more information see the Javadoc for org.eclipse.debug.internal.ui.viewers.model.provisional.IViewActionProvider with an example available in the org.eclipse.debug.examples.ui bundle found in the Platform Debug Git repo.

Equinox Changes

New OSGi console This release includes a brand new OSGi console based on the Apache Felix Gogo project. In previous releases the Equinox framework contained a built-in OSGi console. This console allows you to interact with the OSGi framework and execute commands on the running instance of the framework. For example, it can be used to install bundles or to get a list of currently installed bundles. The built-in console is convenient because it is always available without needing to install extra bundles, but it is also limited because the framework itself must contain all the functionality of the built-in console.

The Apache Felix Gogo project has developed an advanced shell for interacting with OSGi frameworks. Instead of continually enhancing the built-in Equinox Framework console, a new external Equinox Console bundle has been created that uses the Apache Felix Gogo bundles. The new Equinox Console bundle continues to provide support for the Equinox Console APIs (package org.eclipse.osgi.framework.console). It also adds many new enhancements which are possible through the use of the Gogo shell. This includes features such as tab completion, command history, piping, grep, telnet and ssh connections, and more. Type help on the console to see a list of available commands, or help <command-name> for information on how to use each command.

Update to Jetty 8 and Servlet 3.0 The Equinox HTTP service implementation is now using Jetty 8 as the web container to support Servlet 3.0 and JSP 2.2. The Equinox HTTP service is required to host the Eclipse user assistence web context for serving up help content.

For the Juno release, Equinox will no longer support the use of older Jetty implementations and we are no longer shipping Jetty 6. The Equinox HTTP service implementation will no longer work with the Servlet 2.5 and JSP 2.1 APIs. Also note that the Jasper and expresson language implementation bundles have changed in order to support the Servlet 3.0 and JSP 2.2 specifications. The following bundles have been removed:

  • org.apache.jasper
  • org.apache.commons.el
  • org.mortbay.jetty.server
  • org.mortbay.jetty.util
These have been replaced with the following to support Servlet 3.0 and JSP 2.2:
  • org.eclipse.jetty.continuation
  • org.eclipse.jetty.http
  • org.eclipse.jetty.server
  • org.eclipse.jetty.servlet
  • org.eclipse.jetty.util
  • javax.el
  • org.apache.jasper.glassfish
  • com.sun.el

Customize storage for preference scopes When defining your own preference scope, you can now extend a simple storage customization class rather than implementing all the preference logic yourself. In this class you simply define the code to read and write a preference node to whatever backing store you want to use. This makes it very easy to define a custom preference scope with alternate storage requirements. For more details see the documentation for the org.eclipse.equinox.preferences.preferences extension point, or the new API class org.eclipse.core.runtime.preferences.AbstractPreferenceStorage.
OSGi Core Release 5 With this release the Equinox OSGi Framework implements the draft OSGi Core Release 5 (R5) specification. The OSGi Core R5 specification is an incremental change from the R4.3 specification. A majority of the changes included in the Core R5 specification are in support of the upcoming OSGi Enterprise Release 5 specification. A public draft of the specification will be available here by March 26, 2012. The final version will be available here shortly after that.
Publisher Support for Negation Requirements The p2 publisher can now publish negation requirements. A negation requirement is a requirement that must not be present. For example, the Rich Ajax Platform (RAP) can declare a negation requirement on the Eclipse Platform, meaning that RAP won't be installable into your IDE.
Negation requirements are specified using the p2.inf file. Details are available on the Wiki

SWT Changes

Highlight TrayItem Image You can now provide a custom image for use as the hightlight image for a tray item on Cocoa. The highlight image is shown when the tray item is activated. The default tray item image will be restored when the tray item is deactivated.

Default Tray Item
Default Tray Item

Highlighted Tray Item
Highlighted Tray Item

Added support in StyledText to show the scrollbars only when needed In the past, when a StyledText was created with scrollbars it would show them all the time, even when the client area was big enough to show the entire content. By using setAlwaysShowScrollBars() this behaviour can now be configured so that instead of showing a disabled scrollbar, the StyledText will only display the scrollbar when needed.
Event type constants in StyledText are now public The following event type constants in StyledText have been made public:
  • ExtendedModify
  • LineGetBackground
  • LineGetStyle
  • TextChanging
  • TextSet
  • VerifyKey
  • TextChanged
  • LineGetSegments
  • PaintObject
  • WordNext
  • WordPrevious
  • CaretMoved
This allows these constants to be used with Widget#isListening() to verify if a listener handler was added for any event type in StyledText.
Default Browser renderer is now configurable The native renderer that is used for SWT.NONE-style browsers can now be configured by setting a Java property. This is particularly important for applications that create browsers with a specific native renderer style (eg.- SWT.MOZILLA), in order to avoid conflicts that can occur when multiple native renderers are loaded in the same process.

For more information on using this new property see How do I specify the default type of native renderer that is used by the Browser? .

FontDialog Effects New API has been added to FontDialog to prevent the user from selecting font effects, such as color, underline, strikethrough and shadow.

FontDialog on Windows without the Effects grouping

New Combo API Two new APIs have been added to Combo that allow users to get the caret information in a combo box. Combo.getCaretLocation returns the pixel coordinates of the caret. Combo.getCaretPosition returns the character position of the caret.

For an example of how to use this API see Snippet 359.

Tree Cursor The new TreeCursor class can be used to enable users to navigate a Tree control's individual cells, similar to what TableCursor makes possible for Table controls. For an example of using TreeCursor see Snippet360.

Tree Cursor

XULRunner 10 The SWT browser now supports embedding XULRunner 10.0.x (note that XULRunner versions 4.x - 9.x are not supported). Apps wishing to use this must ship a XULRunner 10 runtime and explicitly point at it as described in the FAQ .
Provide context menu trigger MenuDetectEvent now fills in the event detail field to indicate whether the context menu is being triggered by the SWT.MENU_MOUSE or SWT.MENU_KEYBOARD. If the event.detail is SWT.MENU_KEYBOARD, custom controls can appropriately position the context menu based on current focus or selection.
Set/get custom colors in ColorDialog ColorDialog now supports getRGBs() and setRGBs(RGB []) to allow applications to retrieve, save, and restore any custom colors that the user selected in the dialog.

Custom Colors section of a win32 ColorDialog

BIDI segments on text widget The Text widget now supports adding SegmentListener for BIDI support. This allows BIDI ordering to be applied to segments of the text instead of the entire text.
Browser Function Access BrowserFunction can now be installed into specific frames.
SWT Runtime introspection SWT.isLoadable() can be used to determine whether the SWT implementation can be loaded in the current running environment.
Overlay scrollbars Scrollable.getScrollbarsMode() can be used to determine whether the platform shows overlay scrollbars.

Previous     Next