Last week, the Eclipse Foundation released Eclipse 4.0 Early Adopter SDK. This shouldn't be confused with the production-ready Eclipse Helios release (aka Eclipse 3.6). Rather, Eclipse 4.0 is a sneak preview of what Eclipse will look like in the future.
The next simultaneous release of Eclipse (codenamed Indigo, or Eclipse 3.7) will still be based on the existing 3.x stream of code; though there will also be an Eclipse 4.1 stream build as well. So why maintain two public versions for this year and next? The project page has this description:
Eclipse SDK 4.0 is the next generation platform for building Eclipse-based tools and rich client desktop applications. This new release makes it easier for developers to develop and assemble applications and tools based on the Eclipse platform.
The 4.0 release is for early adopters that want to test backwards compatibility and migrate their plug-ins and RCP applications. We expect Eclipse end users will adopt a future release of Eclipse 4.x.
Although Eclipse 4.0 (previously referred to as E4) has been in development for two years, the only prior public release was E4 0.9 in July 2009. The original E4 whitepaper explains some of the thoughts behind the necessity of rethinking the Eclipse platform itself. It describes the Eclipse 4.0 platform as being the third generation platform for Eclipse-based products:
- First generation: Eclipse 1.0 to 2.1. “Primarily an integration platform; its main strength was pulling together diverse plug-ins from different authors, and integrating them into a common application with a consistent and cohesive end user experience”
- Second generation: Eclipse 3.x. “Powered by an OGSi runtime, making it a more powerful general purpose component-based application framework, scaling from very small embedded applications up to large rich client applications and web servers”
- Third generation: Eclipse 4.x. “Make it much easier to write components that are more reusable and customizable for a wide range of applications and environments, by reducing external dependencies and assumptions, and by widening the set of languages and technologies that can be seamlessly integrated.”
Although OSGi continues to serve Eclipse applications well, many Eclipse applications are not well behaved OSGi applications. Primarily this is one of historic provenance; in the pre-OSGi days, there were many singletons (like Platform, PlatformUI and IDE) that acted as God Objects. Not only is this an OO anti-pattern, it also doesn't fit well with OSGi's (dynamic) services.
One way the Eclipse 4.0 platform improves this is by using Dependency Injection (aka DI), popularised with tools like Spring, to make services available on demand. It's even possible to inject these automatically using the javax.inject annotations, coupled with OSGi's Declarative Services (aka DS), to provide E4 or OSGi services automatically to code; for example:
import javax.inject.Inject;
import org.eclipse.e4.core.services.Logger;
import org.osgi.service.packageadmin.PackageAdmin;
public class Example {
@Inject private Logger logger;
@Inject private PackageAdmin packageAdmin;
}
The Eclipse 4.0 platform will take care of injecting the services automatically, controlled externally from the code that needs to use it. (It's also possible to mark a service as @Optional, in case the service isn't necessary for operation.) This should make components much easier to integrate with OSGi componentised, service-based applications. A list of proposed Eclipse Application Services are available.
The other significant change for Eclipse 4.x is the way that the UI is built. In Eclipse 3.x, the user interface is built imperatively; hand-crafted code generates SWT (or JFace) widgets, and places them on screen. Although SWT has arguably better platform-specific rendering performance and behaviour over Swing-based user interfaces, there has historically been some trepidation in using this toolkit. Part of that reason is that SWT-based UIs require a dispose() call when finished, in order to free up system resources. Though not difficult, it is not the norm in Java programs and so leaks are not uncommon; furthermore, in a hosted environment like Eclipse, it only takes one bad plugin to leak resources to cause the system to grind to a halt. Tools exist to help determine such leaks (such as sleak) but it's even better to not have to worry about them.
Instantiations, recently acquired by Google, had an award winning product called Window Builder Pro, along with RCP Designer, which could create a user interface by dragging-and-dropping the components together. Not only is this much easier than hand-crafting code, it also means that the memory requirements can be managed in the generated code, instead of having the coder to worry about it. However, with the acquisition, these products are no longer available – though it is expected that GWT Designer will make an appearance via the GWT Blog in the coming months.
How does this relate to Eclipse 4.x? Well, the other significant change is the development of a declarative-based user interface. Much like HTML, where the UI is declarative rather than imperative, the Eclipse 4.x user interface is specified in a XAML-like or XUL-like fashion. Not only is this easier to maintain, it also means that the rendering engine can handle the construction – and therefore also disposition – of the UI widgets. Finally, it externalises the ordering of the display from the code itself, which means that theming an application can be done externally from code.
Following with the HTML pattern, it's possible to use CSS to specify how the UI should look. It also means that web-based front-ends can closely tie in with the desktop counterparts, simply by generating a different style of user interface from the same underlying declarative representation.
Finally, most of this is possible through representing the application, views and services via the Eclipse Modelling Framework, or EMF. The UI is written by representing widgets and views as models; this means the model can be created up front, or generated, introspected and manipulated at run-time, much like JavaScript can manipulate a web-page's DOM.
As Ian Skerrett noted, this is the start of a journey for the new platform. Whilst Eclipse 4.0 is aimed at early adopters (and there are known issues), the goal is that it should be possible to migrate Eclipse plugins from Eclipse 3.x to run in Eclipse 4.x with minimal changes. Mike Wilson has an interview with EclipseZone on what's important with Eclipse 4.0, and tutorials are available from both Lars Vogel and Tom Schindl