Here are descriptions of some of the changes of interest to plug-in developers made to the Eclipse Platform, Equinox and SWT for the Luna (4.4) release of Eclipse.
New features oriented towards end-users of the platform can be viewed in the What's new section of the Workbench User Guide.
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).
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; @PostConstruct void createView(Composite parent) { label = new Label(parent, SWT.BORDER); label.setText("Testing"); } @Focus void setFocus() { label.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:
|
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 org.eclipse.core.jobs
bundle. Invoking this API has had no effect since the 3.0 release. The specific API
being removed includes:
|
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:
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 org.eclipse.e4.ui.services .
|
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:
|
Locale change consumption |
There are now three ways to be informed about a Locale change:
|
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 |
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:
|
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:
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:
|
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:
|
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 |
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(); |