Eclipse Juno and the Future of the Eclipse Platform

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

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.

I am looking forward to Eclipse 4. It should really reduce my code base. And the ability to easily change the look, is great. The only issue, i currently have is that I need to have a RAP version of the UI and E4 does not seem to be on their radar.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.