Last week, the Eclipse Foundation announced the release of Eclipse Juno M5, a milestone towards this summer's combined release train. It brings new features, such as potential null pointer dereferences and leaked resources (for both Java7, where a try-with-resources can clean it up, and for Java6 using standard try/catch handling.)
For the first time, the combined Eclipse release will be based on E4. This represents a significant re-write of the Eclipse UI infrastructure using declarative EMF-based models instead of code to represent the user interfaces. The model can be introspected and modified at runtime, causing changes to be rendered immediately in the window, as well as providing automatic persistence for saving the view state when required.
One main advantage of declarative modelling for the user interface is that, as with HTML, it is possible to separate out the organisation of the user interface from its presentation. This permits the use of CSS to style the user interface, and separate out the concerns from having to manually manage the user interface components in code – and also therefore avoiding memory leaks through undisposed resources.
Another improvement in the E4 runtime is the use of dependency injection to acquire required services. Previously, static accessors were used to get hold of frequently-used platform services (such as the SelectionService, which provides information when the selection changes between different views). These services have been available since the initial launch of the Eclipse platform, but despite the transition to the OSGi runtime architecture for Eclipse 3.0, the services weren't exposed as OSGi services. With E4, these base platform services are now available as OSGi services, and can be consumed by both Eclipse and OSGi clients.
To facilitate obtaining services which are typically singletons – workbench selection service, logging service etc. – Eclipse plugins can declare an injection point for the required service. When E4 starts and loads the plugin, it will determine what services are needed and then wire them up based on the running platform. This will be a familiar model to those who have used Spring before, but instead of needing to set up an Application Context it comes for free based on the contents of the running platform itself. Injection is done with the standard javax.inject.Inject annotation, which can be done on a per-field or per-method call basis.
Since the mechanisms for looking up services have changed significantly between the old Eclipse 3 runtimes and Eclipse 4, a backward compatibility layer provides the same APIs as expected by plugins targeting the older environment. Note that these APIs are a complete replacement of the previous implementation, and as such may contain bugs and features not present in earlier releases.
The transition to E4 has been a gradual one. First launched as SDK 4.0 after the 3.6 Helios release, a follow-up SDK 4.1 was launched for Eclipse developers after the 3.7 Indigo release. For the upcoming Juno release, the expectation is that users will transition over to the 4.2 platform – although there will be a final 3.8 build available.
However, the Eclipse project has taken its toll over the years. Originally started by IBM, the Eclipse platform has always been heavily weighted with IBM employees. The dashboard lists many IBM and ex-IBM members and a smaller proportion of external committers. In an e-mail to the cross-project list, Mike Wilson (PMC of the Eclipse Project) highlighted that there were just 3 remaining developers on the Platform UI project after natural attrition by their parent companies. This led to concerns being raised as to whether 4.2 would be ready in time for Juno; but with the drawn-out history, Mike argued that a delay would be “catastrophic for our community”:
Some might argue that it would be better to simply release 3.8 into Juno and move ahead with the 4.x stream in a follow on release. Honestly, I believe this would be catastrophic for our community. The Juno simultaneous release is going to be the basis for both the first Eclipse Long Term Support and first Very Long Term Support offerings. Given that, plus the overall maturity of Eclipse and the requirements of many of the large organizations that are participating, I see the Juno release as being extremely important. If we are unable to deliver 4.2 in Juno it would mean that a huge segment of the community would not be able to take advantage of the new features it provides, but more importantly they would be building on a code base that we know needed to be replaced -- that was, after all, the impetus for the 4.x work in the first place. It would literally mean that it would no longer be possible for the Platform (that we all build on) to adapt to the changing needs of modern, desktop applications. And this, more than anything I can think of, would jeopardize the future of Eclipse on the desktop.
He goes on to acknowledge the concerns of single-company sponsorship of the Eclipse project itself, at least in terms of committers:
In the end, what's clear to me out of all of this is that the Eclipse Platform UI team, and indeed the Eclipse Project as a whole, *needs* more non-IBM committers now. And by that I mean more, *active*, "working on the SDK for the good of the community in general" people. All those arguments about lack of diversity on the Eclipse Project are coming home to roost: It is clear now, that the remaining IBM Eclipse committers are too few to support the entire SDK
Wayne Beaton, evangelist for the Eclipse Foundation, believes that vendor neutrality in an open project is not only essential, but required by the Eclipse bylaws:
The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the “Eclipse Platform”).
Finally, The Eclipse Foundation also decided that next year's release train will go by the name of Eclipse Kepler. Although there was a previous project proposal also called Kepler, the project never gained momentum and was archived shortly after it was proposed. Look forward to Eclipse Kepler, built on Eclipse 4.3, to arrive sometime in Summer 2013.
