Eclipse 4 – The Next Generation Platform

Appearing in JAX Magazine’s special Juno issue back in June, Brian de Alwis discusses the genesis of Eclipse’s next-generation platform.

Appearing in JAX Magazine’s special Juno issue back in June,
Brian de Alwis discusses the genesis of Eclipse’s newest platform
and what’s different. Note: This was written before performance
issues came to light.

This year’s Juno release sees the mainstream deployment of
Eclipse 4, the new application platform from the Eclipse
Foundation. Over four years in the making, Eclipse 4 is a
substantial re-imagination the Eclipse platform. This article
provides a brief history of the Eclipse 4 effort and highlights
some of the more interesting new features of the Eclipse 4
application platform available in the Juno release.

What is Eclipse 4?

The Eclipse 4 effort began in 2007 with a question: if we
were to re-implement Eclipse now, what would we do differently? The
technology world of 2007 was very different from 2001 with new
techniques, new technologies, and new expectations. What did we do
right? What deficiencies would we rectify? What proven solutions
from elsewhere could we leverage to improve the Eclipse platform?
The discussions were wide-ranging and touched many areas of the
platform. An incubator project was struck to host some of the
redesign, called “e4”.

The most significant changes centred around the Platform’s
Workbench UI model. Although the classic Eclipse Workbench model,
with its views and editors, has been enormously successful, time
and experience had revealed issues. Some parts of the API were
difficult to learn.The view/editor model was felt to be too
limiting for some types of RCP applications. Much of the UI
implementation was considered to be internal, meaning that it was
difficult or impossible for apps to manipulate the UI (e.g., to
programmatically split the editor stack) or to introduce new UI
abstractions into it the platform. The codebase had become brittle
and difficult to change: although new UI extension mechanisms had
been introduced over time (e.g., the transition from actions to the
new command/handler regime), the older mechanisms were still
supported because of Eclipse’s backwards compatibility
requirements.

A radical plan was hatched: replace Platform/UI with a new
approach based on the best practices learned from Eclipse 1.0
through 3.x. The new approach would separate the conceptual UI
model from how it was rendered (e.g., SWT, JavaFX), and allow for
extensibility. There would be no “internals”: all parts of the
model would be public and available to all.

But what of the millions of lines of existing Eclipse 3.x
code? Abandoning the 3.x APIs was not an option: there was simply
too much existing code to be por ted to a new API. And the 3.x
Workbench APIs are enormously rich and powerful. Rather than
replace the APIs, a “Compatibility Layer” would be built to bridge
the Eclipse 3.x APIs on top of the new approach, and in the process
proving that the model was sufficiently flexible — the bridging
layer would itself become an app built on the new APIs.

Architecture

The Eclipse 3.x Workbench UI was originally structured as
a thin extension layer atop JFace/SWT. JFace/SWT provided the
mechanisms for managing a UI (e.g., resource registries, windows
and dialogs, key bindings), and the workbench defined various
extension points for plugins to extend and customize the workbench.
Over time, additional areas of functionality were added to the
workbench, including theming support, control over the
visibility of UI elements, accessing additional services.

Eclipse 4 breaks the workbench layer into two parts: a new
Eclipse 4 Application Platform that builds on top of JFace/SWT, and
a re-implementation of the Eclipse 3.x Workbench APIs on top of
this new Eclipse 4 Application Platform. Eclipse 4 is based on the
best practices from Eclipse 3.x, and so most of the knowledge that
developers have from Eclipse 3.x will carry forward.

Benefits

The new Eclipse 4 Application Platform has a number of
important features for application developers:

A simplified and extensible workbench model

The original Workbench UI model has been simplified and is
now represented through an EMF-based model. The model is entirely
public (see below), and allows programatic access to the UI model.
This access means that a plugin could easily provide code to split
an editor stack, or move a part from one part of the
window.

New types of model elements can be added to better
represent an application’s UI requirements. For example, some work
is ongoing to address the long-standing request to support split
editors in Eclipse (the infamous bug 8009).

And the model can be introspected upon at runtime. The E4
Model Editor can be launched on the active application, which is
very useful for debugging.

A flexible theming and rendering approach

The Eclipse 4 UI model is realized for particular widget
toolkits through a pluggable rendering implementation. Eclipse 4
ships with an SWT-based rendering system, but other systems are
being prototyped for JavaFX and Swing/AWT. New renderers can be
created for different model arguments. Changes to the modelled
elements are reflected in the UI, and vice versa.

Eclipse 4 uses CSS, a proven technology from the web, to
providing theming support. CSS is a much more flexible mechanism
than the olderWorkbenchTheming support provided in Eclipse 3.x. In
Eclipse 4, a window is considered as a document, and the widget
hierarchy corresponds to the DOM. It’s a surprising connection but
the approach works very well in practice.

Simplified access to application services

One of the primary attractions for developing for Eclipse
are its rich application services. Beginning and intermediate
application developers frequently had difficulty locating various
application services such as the status line manager. Rather than
having to through navigate a chain of objects, services are now
provided using Dependency Injection (DI).

DI separates the configuration of an object from its
behaviour. Rather than clutter an class with details on how to
access its required dependencies, the dependencies are instead
configured through the use of an injector. Eclipse 4 provides such
an injector, and manages the objects that it creates. Unfortunately
describing DI is beyond the scope of this article; the Eclipse 4
website has some references for further
information. Recording (and reacting to) application
state

One difficulty faced by many developers ith Eclipse 3.x
was how to maintain and scope application- specific state. For
example, some applications may wish to maintain a different
database connection for each window, or each view. With the Eclipse
4 framework, model elements support recording three types of
application data:

Applications and plugins can add their own keys and tags.
Changes to these data items, indeed to any model element, are
broadcast through the OSGi EventAdmin service, a pubsub
mechanism.

The platform also provides a powerful service lookup
mechanism called an Eclipse Context. A context is a transient map,
and contexts can be linked together to form a tree structure. On
lookup, when a key is not found in the starting context, then the
lookup is retried from the context’s parent. This lookup repeats
until either a value is found or the root of the tree has been
reached. Interested parties can be notified of changes to context
values.

The power of contexts comes as there is a context
associated with most model elements. At the top of the tree is a
special node that looks up keys among the available OSGi services.
Many application-, window-, and view-level services are installed
by the Eclipse 4 at various levels in the context hierarchy.Thus
the placement of values within the context hierarchy, such as in
the perspective or window’s context, provides a natural form of
variable scoping.

Adding to the power is the additional facility to declare
context variables. A context variable is a normal context key but
associated with a particular context.That variable is updated
regardless of which of that context’s children modifies the
variable, thus allowing the definition point to be changed
independently of the code using those variables.

Contexts are used as the injection source for DI, and
application code is expected to rarely need to interact with
contexts directly.

Caveats

Although there are already commercial applications
shipping on Eclipse 4, the programming interfaces are still young
and considered to be in an provisional state and thus subject to
possible change. Although we do not anticipate making significant
changes, we may need to tweak the APIs based on feedback. We
welcome feedback, particularly your experiences in using the
Eclipse 4 platform for RCP development.

Since the Eclipse 3.x Compatibility Layer is written using
the Eclipse 4 application platform, any application using the
compatibility layer is now also an Eclipse 4 application.The
compatibility layer supports only very limited interaction with
other Eclipse 4 apps or contributions. This is an area of active
interest and we recommend visiting the Eclipse 4 wiki for the
latest news.

Conclusion

The mainstream release of Eclipse 4 marks a new beginning for
the Eclipse platform. We’ve highlighted some of the more
interesting new features, and hope that they have whetted your
appetites to try them out for yourselves. For more information,
visit the Eclipse 4
site. From there you will find pointers to tutorials and
guides. We welcome feedback on the programming interfaces, either
to the Eclipse
4 Forum or the e4-dev mailing
list (for more technical discussions).

Author Bio:

Brian is a committer on the Eclipse Platform/UI team and the
creator of Kizby, the first commercial quality application built
using the Eclipse 4 platform.

This article appeared in JAX Magazine: Eclipse Juno,
featuring many projects from the Juno release train. Find that and
other issues here.