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.
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.
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:
- transient-data (Map<String,Object>) discarded on application exit
- persistent-data (Map<String,String>) persisted and restored on application restart
- tags (Collection<String>): persisted and restored on application restart
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.
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.
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).
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.