Eclipse e4 0.9 - New and Noteworthy

The ancients, who were our betters and nearer the gods than we are,
handed down the tradition, that whatever things are said to be are composed
of one and many, and have the finite and infinite implanted in them.
- Plato, Philebus

Welcome to the very first release of the e4 project! This first release, version 0.9, is an alpha release intended to give the community a preview of some of the exciting new technology being developed by the e4 project. The project is being developed by a diverse group of contributors, and we're always looking for more participation. So, check out the examples, dive into the code, and join in the development discussion on the e4-dev mailing list.

Here are some of the more noteworthy things available in the e4 0.9 release, available for download from the Eclipse e4 Project downloads page.

Compatibility: on the road to self hosting e4 provides a compatibility layer that allows existing Eclipse 3.x applications to run on top of the e4 platform. This allows applications to leverage new e4 technologies such as widget styling and user interface modeling, while allowing plug-ins written for previous Eclipse releases to continue running. This compatibility layer is still in its early stages in the e4 0.9 release, but supports basic self-hosted development in the Eclipse SDK running on top of e4.

e4 self hosting

Dependency injection Client-supplied implementations for components such as views and editors no longer have to extend framework classes, or implement framework interfaces. This has two advantages:
  • It makes UI components reusable in different contexts, for example in sub-panes of editors, or in dialogs or wizards.
  • It enables implementations in other languages. Presently, JavaScript is supported.

Rather than depending on "hub" interfaces like IWorkbench, UI components express dependencies on individual services. Examples of services are error logging, preference store, and styling engine. This set can be extended by application developers.

Dependency injection is used to supply these services, along with other required objects, to the constructor of the client object. For example, in the snippet below, the parent composite and the styling engine are both thus supplied.

source code of location view

Dependency injection with annotations The dependency injection mechanism uses Java 5 annotations to decide which fields and methods to inject. For applications that cannot use Java 5, injection points can also be identified using method and field name prefixes, or on field type. We experimentally support different annotations from existing dependency injection frameworks: for example, @Inject and @Resource. At this point we recommend using @In for values and services that should be injected, @Out for bean properties that should be observed by the context, and @PostConstruct for methods that should be called after constructing an instance and injecting all values and services. There are no code dependencies on existing dependency injection frameworks. These annotations are defined in the bundle.

For an example, see in the e4 photo demo application.

source code of view using annotations

Hierarchical contexts The bundle 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.
  • Pluggable context lookup strategies. When a context cannot find a defined value for a given name, it will consult its ILookupStrategy to determine a value. This allows integration of external service lookup systems with e4 contexts, such as the OSGi service registry.
Creating widgets with models Modern web UIs are built on a combination of HTML and JavaScript. The HTML+JavaScript combination has proven highly effective, perhaps because HTML is easier than programming, perhaps because scripting HTML instances is easier than programming Java classes. However, the combination has its weaknesses. Working with HTML+JavaScript as text is error-prone, while programming against the HTML DOM is cumbersome.

In the context of e4, we're exploring a similar programming model and try to build on its strengths, while avoiding its weaknesses. The GUI is represented as a model instance, in the same way a web page is an instance of the HTML schema. However, instead of using XML for the model, we use the Eclipse Modeling Framework (EMF) and its Ecore language. EMF provides a clean set of concepts and simple, generic tools for modeling, and is a lot simpler than XML.

The Toolkit Model (TM) currently supports most simple widgets and containers, while complex widgets like trees and tables are in the works. TM is designed to be extended with custom widgets, that are either implemented in Java or composed by existing ones.

Live models and JavaScript As with HTML, the GUI is rendered by an engine using the platform's toolkit. The GUI is updated whenever the model instance is changed, similarly to how changes to the HTML DOM affects the web page's content and appearance.

JavaScript is used for reacting to user generated events and updating the GUI in response. However, since EMF and the JavaScript engine are Java-based, we can easily use Java instead. If EMF is used for modeling the application data, JavaScript may also be used for implementing the application logic, making it perfect for rapid prototyping.

Model editing tools We currently provide views and editors for the Toolkit model, based on the generic EMF tools. GUIs are built using the Ecore editor, and a preview continuously shows the resulting GUI. GUI fragments may be dragged from a palette view into the editor.

When EMF is used for modeling application data, a complete, functional application may be created by combining a scripted GUI with sample application data, as shown below.

Model editor with prototype

Photo demo Example applications are a valuable way of demonstrating the power and flexibility of e4 outside the domain of development tools. One such exemplary e4 application is the e4 photo demo. In its current form, the photo demo application supports a library of albums containing photos, a preview pane, a thumbnails view, a view showing image metadata, and a view that shows Google Maps if the currently selected photo has embedded GPS coordinates. The photo demo illustrates the following e4 concepts:
  • Injection of services in views, making view implementations much simpler
  • Alternate workbench layout using a customized e4 workbench model.
  • Custom view presentation using CSS

Screenshot of e4 photo demo

Contacts demo Another sample e4 application is the e4 contacts demo. This application is a simple RCP application for displaying and managing personal and business contacts. The purpose of the contacts demo is to show the following e4 capabilities:
  • Customizing the look and feel using CSS
  • Product branding
  • Data binding
The current implementation comes with several themes that can be switched dynamically.

contacts demo

e4 on the Rich Ajax Platform (RAP) The Eclipse Rich Ajax Platform (RAP) project provides an SWT API that bridges the gap between the desktop and web.

It is possible to run the various e4 examples as web applications using RAP. RAP currently provides an experimental branch that contains enhancements to make it easier to run your applications on both the web and desktop with minimal changes.

As the Platform itself concentrates on being more multi-user friendly, it will be even easier for application developers to single source their e4-based applications across the desktop and web in the future.

The Foo View

To try it out, just follow the e4/RAP integration tutorial.

Modeled User Interface
Application model Applications built on e4 are composed of UI elements (menus, toolbars, parts such as views and editors, etc). The runtime configuration of the UI elements is described by an EMF model, from which SWT widgets are generated. By making the application model explicit, the programming model becomes clearer for developers. This will make it easier to both extend an existing system and compose RCP style applications. It also drives better architecture in the way parts are defined and assembled, with the future goal of more flexible composition of workbenches to address non-IDE requirements.

photo demo model

Schema By using EMF for the application model, its schema is specified in the form of .ecore files. The base schema, called Application.ecore, contains types that are useful for any desktop UI application. Eclipse-specific extensions to that model, such as perspectives and views that are shared across perspectives, are in a separate schema, Workbench.ecore. Other applications or platforms may use the same technique for extending the schema as needed, and at the same time, we keep the complexity of the base schema at a minimum.

model schema

Persisting state Application state is persisted across sessions by saving the EMF model. Individual parts can persist their state (for example, table column widths) by making a bean property available and marking it with both @In and @Out annotations.
Embedding modeled UI elements in dialogs and wizards Eclipse has had a long-standing request to be able to reuse parts of the Eclipse UI in dialogs and wizards. In e4 this level of reuse is now possible! You can now create a model (exactly as you would for the regular e4 UI) and use it to populate all or part of a dialog or wizard page's content.

Modeled Dialog

The above screen shot from the e4 photo demo illustrates a dialog containing two views that are also available as traditional views in a workbench window.

E4 model viewer The E4 model viewer shows the contents of the running model and can be used to modify some properties of the model elements:

E4 Model Viewer

E4 Model Viewer Advanced tab

The model viewer also includes a JavaScript tab where you can execute scripts against the selected model element, much like you would run snippets in the Java debugger.

E4 Model Viewer JavaScript tab

Declarative Styling
Declarative styling with CSS SWT widgets can be styled in e4 via Cascading Style Sheets (CSS). This work originated in the TK-UI project and has been adopted as part of e4. Widgets can be styled by widget class name, or can be tagged with an ID or a CSS class name. Many properties are supported such as fonts, colors, and border widths. In addition, some custom pseudo selectors such as CTabFolder:selected can be used. Most of the SWT widgets, as well as the Nebula Gallery widget, can be thus styled. The long term goal is to modernize the look of Eclipse based applications, and making Eclipse components more reusable by separating styling logic from application structure and behavior.

There are several examples showing the capabilities of CSS-based styling. To get a feel for what can be done, there is a handy live editor with a set of SWT controls, and a stylesheet that can be edited. Changes in the stylesheet are immediately reflected in the widgets in the editor. Similarly, one can audition styling of the Gallery widget in its example editor.

Picture showing the CSS SWT Editor example

CSS support can be used separate from the rest of e4. The RCP mail application example demonstrates this, showing that one can style many aspects of an existing Eclipse 3.5 based RCP application. The example has as its base the same one generated as a plug-in example in the Eclipse SDK, with CSS support added to change fonts, background colors, and tab colors.

Picture showing the CSS RCP example

New tab folder look

There is an optional new tabbed folder look (classes ETabFolder and ETabItem). This is a prototype and under construction. The modeled UI now creates it by default in the StackModelFactory, however you will get the CTabFolder look by default. To get the new look, specify in your CSS:

ETabFolder {
   webbyStyle: true;

New Folder Look

Gradients Declarative styling in e4 also supports gradients. For CTabFolder, the gradients are set directly on the widget using the widget's API. For other widgets, they are implemented by painting the gradient on the widget. For the latter, this allows us to support both linear and radial gradients. The radial support is currently very basic but a good starting point for further enhancements. In the e4 contacts demo you find some examples for both linear and radial gradients. Radial gradients are currently only supported with Java 6.

For example, to specify a white to mid gray linear gradient on the selected tab of the CTabFolder, you can write:

CTabFolder:selected {
   background-color: rgb(255, 255, 255) rgb(240, 240, 240);

Here are some examples of both linear and radial gradients:

gradients examples

Margins for spacing between widgets

There is now experimental support available for specifying margin sizes. They can be specified independently on all four sides of a widget. However, they require the creation of a dedicated composite and layout. As such, in the modeled UI, only the StackModelFactory supports margins.

The CSS markup is the standard CSS you'd use in HTML, with values in pixels. So for example:

CTabFolder {
   margin: 5px; /* 5 pixels all around */

CTabFolder {
   margin: 5 10 15 20; /* 5 top, 10 right, 15 bottom, 20 left */
Extensive CTabFolder support

Most CTabFolder setter methods now have an equivalent in CSS. For example you can say:

CTabFolder {
   color: black;
   background-color: rgb(246, 246, 251);
   font: normal;
   simple: true;
   maximize-visible: true;
   minimize-visible: true;
   tab-height: 20px;
Modeled UI informs of active state

The SWT CTabFolder only maintains two color states, one for the selected tab and one for the other tabs. However, the observant Eclipse user will notice that there's also the notion of the active stack, being the last one which had focus. For example, if the Packages views is selected but I'm working in the editor, both are selected, but only the latter is active.

In order to style these differently, the modeled UI sets the CSS classname on the widget to ".active". This is done via the IStylingEngine service. The matching CSS then determines how to style the tabs, and all four states can be represented as:

CTabFolder {
   color: black;
   background-color: rgb(241, 240, 245);
   font: normal;
   simple: true;
CTabFolder:selected {
   background-color: rgb(255, 255, 255) rgb(246, 245, 250);
} {
   background-color: rgb(241, 240, 245);
} {
   background-color: rgb(255, 255, 255) rgb(255, 247, 229);
CTabItems are styleable

You can now use CTabItem as a selector within your CSS. Currently supported properties are fonts and show-close, and the pseudo selector :selected. This allows you write expressions like "all editors show their close boxes but only selected views show theirs" as follows:

CTabFolder.editors CTabItem {
   show-close: true;
CTabFolder.views CTabItem {
   show-close: false;
CTabFolder.views CTabItem:selected {
   show-close: true;

Additionally, one can imagine expressions like the following which would implement a common UI feedback mechanism in Eclipse, in a first class way. This in particular shows the power of separating semantics (captured in the model) from look (captured in CSS):

CTabItem.modified {
   font-weight: bold;
CTabItem.busy {
   font-style: italic;
Button and Label alignment

Buttons and labels can have their alignment (alignment:) set from within CSS. All the standard SWT alignment keywords can be used (e.g. "left", "right", etc.)


To find out which CSS property keys and values you can use for a given widget class, please consult the following table on the wiki

Web Components
JavaScript modularity e4 includes an experimental framework for writing modular OSGi-style bundles purely in JavaScript. These JavaScript bundles can be run alongside regular Java OSGi bundles in a single process, and interaction between Java and JavaScript bundles can occur in either direction. For example a purely JavaScript extension can be added to the Eclipse extension registry, and the extension can be loaded and used by a traditional Java bundle.

Clone of PDE Site Manifest Editor An experimental "clone" of PDE's Site Manifest Editor has been implemented using HTML, CSS, JavaScript, and Dojo on the client side, and a RESTful API on the server side. This editor works in all major browsers and shows that the current UI Forms look can be implemented using web technologies.

web browser with site manifest editor

Integration of Web UI Components An early JavaScript API is available for integrating web UI components into a desktop Eclipse in a first class way. For example, notice how the web-based Site Manifest Editor appears as an editor in Eclipse, with proper dirty indication and the ability to save using the File > Save menu entry.

Desktop Eclipse with integrated web-based editor

To open a site.xml file with the web-based editor, use Open With from the file's context menu.

Note: On Mac OS X, the embedded web UI does not currently work. As a workaround, add "-Dorg.eclipse.equinox.http.jetty.http.port=8080" to the end of the eclipse.ini file.

XWT comes to e4

The XWT declarative widget framework is part of the e4 0.9 release. XWT allows you to specify UI components declaratively, thus separating the design and structure of your UI from specific implementation details. Repetitive boilerplate SWT code is generated automatically from the xml-based UI declaration, thus reducing development cost, improving UI consistency, and opening the door to skinning or otherwise customized rendering of an application.

XWT supports all standard SWT layouts such as FillLayout, FormLayout, GridLayout, RowLayout, StackLayout. It also handles all SWT events and an additional loaded event. The loaded event occurs when the resource file is loaded, and is used by the control class for the purpose of initialization. A convenience method InitializeComponent can be used in your control class for the same purpose.

Dynamic event handling

The association between UI widgets and your control class is setup automatically during UI loading. In the following example, the event SelectionEvent is handled by the method selection of ButtonHandler.

Here is the class implementing the event handler.

In this example, when the button is clicked the content is changed to "OK".

Support for JFace viewers

XWT supports JFace ListViewer and TableViewer. The following Viewer binds to a Company object. The "input" data must be an array or a collection.

Here is an example using ListViewer.

Below is a TableViewer example with the definition of two table columns.

Custom widget support

XWT supports directly integrating user-defined SWT widgets in your declarative UI. In the following example, a customized UserControl widget contains a button that responds to a selection event.

Now we can integrate the custom control directly into a new XWT component:

Here is the result:

Specifying and customizing style

All controls in XWT can have an additional style property. This property specifies a style object that defines widget properties such as fonts, colors and images.

In the following example, we define a style with a background color of red, and apply it to a label control:

You can also define a style for a specific widget type. It is applied to all UI elements of this type under a given UI tree structure.

In the following example, the MyUserControl component consists of a Label with text "Hello, world". We embed it into a customized component and declare a style to be applied to components of that type.

In addition to embedded XML-based style, XWT provides a customizable styling mechanism. Styling can be applied at several levels:

  • Application
  • Resource view
  • UI element

Integration with e4 CSS is already provided as one of the standard styling solutions.

CSS Integration CSS integration in XWT supports the CSS class selector. This relies on XWT's external namespace handling mechanism. An external namespace is defined for CSS: All attributes prefixed by this namespace will be handled by the CSS namespace handler to set the corresponding information in the widget for the CSS engine.

Here is the code in the e4 contacts demo that integrates CSS styling with XWT:

  <Composite xmlns=""

   <Label text="{x:Static c:Messages.General}" css:id="SeparatorLabel" />


JFace data binding support

XWT directly supports JFace data bindings. Each node in the XWT tree structure has a data context. If a node does not have a data context specification, it inherits the data context of its parent. The data binding expression relies on the data context of a node in the UI tree.

In the example below, a JFace list viewer is bound to the set of employees in a Company object.

Data binding path expression support

The presentation of data through references can be expressed in a path expression.

The following example shows the city of the manager of a company, which is the data context of window. The path is specified as "".

Debug tracking

Data binding requires a consistent configuration between the data model, binding expression and UI structure. In real world applications, this relationship quickly becomes complex and trouble-shooting can be onerous without tooling support. XWT supports an option to print out the UI element tree structure with the associated data context and data binding expression. This option facilitates identification and resolution of data binding bugs.

Take the example above, add an event button. Run the project.

Click the button. The log is displayed in the Console.

Command support for MenuItem and Button

A command is behavior associated with a widget selection event. It is defined on Button and MenuItem, for example the action "Open" or "Close" to open or close a window. Commands must be registered programmatically with the framework:

XWT.registerCommand("<command name>", aCommand)



XWT includes simple internationalization support in the current release.

In the example below, the content of the button is specified by the "title" value of a file.

Multiple data binding models Data binding depends closely on a particular data model. For Java, the first class data binding model is Java Beans, which is already supported in previous versions of XWT. An enterprise application also deals with other data models such as XML, EMF Ecore, RDBMS, Web services, etc. A flexible and customizable solution in XWT is absolutely necessary to support all possible data models.

XWT introduces a new concept to handle some different types of data than plain old Java objects (POJOs). This concept relies on the classes IDataProvider, IBindingContext and IDataBinding. Each data type should implement these three types to integrate their data model with XWT's data binding engine. The Java Bean data binding is mainly handled by the class ObjectDataProvider.

A new plugin "org.eclipse.e4.xwt.xml" has been added to implement the XML data provider.

Widget binding Widget binding is a kind of data binding between UI Widgets. In MVC terms, every widget can be used not only as a view, but also as model. Proper synchronization between UI widgets provides a powerful declarative solution to simply handle dynamic aspects of UI design and to get rid of bulky listeners in Java code.

This solution relies on the new features of JFace data binding for SWT.

The following code is used to bind the selection state of two Buttons on the property "Selection".

Code example

bound widget one

The widgets in the left column are in sync with the respective widgets in the right column.

bound widget two

A single widget can also be bound to multiple widgets. In the above case, the text of two Combo instances is synchronized with the "background" and "foreground" of a Label. When the selection of either Combo changes, the label appearance gets updated immediately.

Advanced UI mediator wizard A mediator in XWT handles the interactions between users and application data via graphical UI. It is a data presentation unit consisting of up to four elements:
  • View: the graphical user interface
  • Controller: the agent to deal with UI events and application logic
  • Data context: the type of data to show
  • Meta-model service: provides the structure of mediator

Each mediator can be plugged in anywhere under the same kind of data context.

The UI Mediator wizard allows you to create a mediator from a selected class, which is used as the data context.

wizard one

wizard two

This wizard will create a mediator with three files: XML view, Java controller and Meta-model service in Java, and it will generate the default content based on the data context model.

Here is an example of a person object with attributes: name, age, nationality and a reference address.

person demo

Multiple loaders XWT allows you to specify a custom XML UI loader. For example, this can be used to develop a model to model transformation engine.

Each UI loader must implement the interface IXWTLoader, and the class XWTLoaderManager is used to activate or deactivate an XWT Loader.

Control binding

Control binding has been extended to support JFace viewers as a data binding source. This enables declarative JFace event handling to synchronize with other UI's state.

For example, in the XWT version of the e4 photo demo, MenuItem's property "enable" is bound with the selected item "singleSelection" in a ListViewer.

External namespace handling An external namespace is a namespace that is not handled by default by the XWT loader. The XWT loader only takes care of the following namespaces:
  • Namespaces prefixed by "clr-namepsace:"

All other namespaces are considered as external namespaces and ignored by default.

XWT includes an extensibility mechanism to handle external namespaces. In particular, an INamespaceHandler must be registered via XWT for each external namespace class beforehand:

    XWT.registerNamspaceHandler(String namepsace, INamespaceHandler handler);

The handler is called when the XWT loader reaches an attribute declared in the external namespace.

This solution can be considered as an annotation, which is used to associate user-defined information with XWT elements.

Workbench integration The plug-in org.eclipse.e4.xwt.ui.workbench contains some common classes and tools to facilitate integration of XWT into the e4 workbench.

Two wizards are available in to create e4 view parts:

  • New e4 Static View Part
  • New e4 Dynamic View Part

The static view part wizard is used to create a part whose content is described in an XWT resource file, which can be either local or remote. The dynamic view part wizard is designed to create a UI at runtime via a Java class.

The static view part should be a subclass of XWTStaticPart, which manages the communication between the e4 workbench and XWT.

EMF data binding XWT provides an extensible mechanism to support other kinds of data. This mechanism is used in the plug-in org.eclipse.e4.xwt.emf to support data binding with EMF data.
Local value converter A converter is needed to convert data from a data binding source to a data binding target in the case where two bound properties' types are incompatible. By default, the XWT data binding engine looks for a converter registered with XWT.

XWT supports specification of a converter inside the binding expression, which can be used only for a single binding.

The data binding can be expressed in extension markup language in an attribute value:

    <Label text="{Binding Path=name, converter=y:MyConverter}"

or in pure XML:

      <Binding path="name">
XWT editor palette customization

You can extend the tool palette of the XWT UI editor via an Eclipse extension point. The following extension defines a custom catagory "My Category" with a tool named RadioGroup. The attribute content contains a text block, which is used to insert in XML code when we drag and drop the tool in XML editor. The content's value may contain template variables since the Eclipse template engine is used during the insertion.

       name="My Category">
            content="&lt;RadioGroup x:style=&quot;SWT.NONE&quot;&gt;&lt;RadioGroup.layout&gt;
                 &lt;GridLayout numColumns=&quot;1&quot; 


XWT contact demo

The e4 Contacts demo is used as an example of the integration of XWT in the e4 workbench. Two view parts "Contacts List" and "Details" are developed in XWT with the CSS support.

The source can be found in Bug 279047

XWT photo demo As with the Contacts demo, the e4 Photo demo is used to validate the XWT architecture. The Exif view part and Exif editing dialog are developed in XWT.

This example illustrates the following features in XWT:

  • Control/Viewer binding
  • CSS integration

Here is the Exif view in XWT:

Below is the Exif editing dialog in XWT:

The source can be found in Bug 263720

SWT browser edition e4 includes a new port of SWT called SWT Browser Edition (SWT/BE). This port allows existing SWT applications to run in the browser using various web user interface technologies. The initial port compiles to ActionScript and runs on the Adobe Flex platform.
ActionScript development environment To facilitate the development of SWT applications in ActionScript, the first pass at a development environment has been implemented. The end goal of this work is to provide a seamless Java coding experience for SWT/BE that is similar to the desktop. Features include:
  • Debugger support
  • Incremental build support
  • Launch support
  • Code completion for the subset of the Java class libraries used by SWT/BE
  • Error reporting

Here is the debug view. You can set breakpoints and step in Java code that is cross-compiled to ActionScript. When you step through the Java code, you are actually stepping within the Flash player. You can click on stack frames and inspect variables.


Just like on the desktop, you can concentrate on writing your Java code and let the project builder automatically build and keep your project's ActionScript code incrementally up to date.


You can configure, run and debug your application using the integrated launch support. The launch support allows for both static and dynamic linking of ActionScript code in the generated SWF files. SWFs are automatically deployed to a local Jetty server, provided by the launch support.


When you type, code completion is provided against the subset of the Java class libraries that ship with SWT/BE. This means that you will not reference classes or methods that do not exist in the subset.

Code completion

For debugging purposes, you can monitor build progress in the ActionScript console.


SWT JCL and 1.5 support The new SWT JCL includes new 1.5 classes and language constructs compliant with most of the Java 1.5 specification.
Incremental J2AS compiler The incremental Java to ActionScript compiler takes existing Java code and translates it to equivalent ActionScript code, optimizing it wherever possible. It also provides mapping functionality which enables debugging.
J2AS execution environment A new J2AS Execution Environment was defined which allows launching of ActionScript applications in a user specified browser.
Deploy ActionScript project A new ActionScript export wizard was added which deploys a compiled ActionScript project to a specified server location. For more information, see the e4 SWT wiki page.

Export deploy

Theme support Theme support was added to both the launcher and the export wizard. This allows new or existing ActionScript themes to be applied to a compiled project.

Theme before

Theme after

SWT/BE examples Here are some examples of the SWT Browser Edition:

Basic hello world example:

Hello World

Control Example which shows all of the SWT controls:

Control Example

Draw2D example which shows an app making use of the Draw2D libraries to draw some diagrams:


The Flickr example demonstrates how an SWT app might make use of REST services. This simple app queries and displays pictures obtained via Flickr Services.


Flexible Resource Model
Project linked resource variables Linked resources with relative locations can now use a variable list that is defined in the project itself, instead of only relying on the workspace variables. The linked resources can also be specified as relative to the project directory itself, making projects referencing other files outside of the project directory portable across workspace and computers.

project variables properties page

Groups Groups are virtual folders that you can use to create an arbitrarily complex logical project independent of the file system hierarchy. Groups, as opposed to regular folder resources, do not exist on the file system. Therefore, groups do not automatically pick up any additional resources underneath them when they are refreshed. Groups can only contain other groups or linked resources as children.

Groups are fully compatible with the existing 3.x Core Resource API, and all plugins work just as expected. Groups are seen internally by clients as a linked resource folder with a null location (IResource.getLocation() returns null).

New group wizard

Resource filters Resource filters can be added on any project, folder, linked resource folder, or group to limit what files and folders in the file system are visible to the resource workspace layer.

Resource filters are a powerful feature that allows an Eclipse project to include folders that contains thousands of elements, but only include a fraction of them in the project. As opposed to UI view filters, resource filters are applied at the lowest level, and do not incur any performance cost for excluded files and folders.

Resource filters properties page

Linked resource editor Under the new Linked Resource project property page, a new Linked Resources tab is available. This tab shows a list of all resources in the project, and group them by their location path, being either invalid (for broken paths), absolute paths (which makes them non-portable) and correct paths.

You can then easily see which linked resource requires modification, and change it directly in the dialog by choosing the Edit... button. You can also automatically convert one or many linked resources to absolute or relative paths by clicking on the Convert To Relative/Absolute button. This command will automatically generate linked resources if needed and try to make the path as portable as possible.

Linked resources properties page

Create filters during resource creation You can now create resource filters directly in the wizard when creating a new file or folder. Click Advanced>> to reveal a button for adding filters to the file or folder being created.

Create filters in new folder wizard

For more information on e4, please see the e4 home page, and the e4 wiki.