Skip to main content
Jump to: navigation, search


In July 2010, the Eclipse Project is scheduled to release a major new release version 4.0. This release is not a typical Eclipse project release, as it represents the culmination of several years of work in the e4 incubator. This FAQ describes what this release is about, what to expect from it, and who should be interested in it.

Eclipse SDK 4.0 Early Adopter Release


Who is the target audience for this release?

The audience for this release is developers who are producing products and plug-ins on top of the Eclipse platform. This release provides them with a stable base to test their software against and report any problems in the Eclipse project 4.0 technology. They can also explore the provisional APIs for interacting with the new platform technology, and provide feedback to the platform developers to help evolve them into future full platform APIs.

Where can I download it?

The Eclipse SDK 4.0 early adopter release is available from this location.

For End Users

I use the Eclipse SDK as a Java IDE - should I adopt the 4.0 release?

Probably not. If you like to live on the bleeding edge you are more than welcome to try it out and report bugs and feedback. However, although the Eclipse SDK 4.0 by itself will be well tested, we can't vouch for any other plug-ins or features out there. So, you may not be able to install any extra extensions that you usually use in your daily work, or you may be able to install them but they may not work smoothly. We are producing this release so that the developers of all those plug-ins can adopt it and validate that their software still works properly.

What major problems or limitations appear in this release?

Given the focus on early adopters for this release, some features and polish items were deferred until the next release. An overview of these limitations, as well as a list of known issues, can be found on the e4/SDKMissingFeatures page.

Why is it called an 'early adopter' release?

The true strength of the Eclipse platform comes from the large community of projects built around it. For example, most end users no longer download the classic Eclipse SDK, but rather download one of the integrated product suites produced by the Eclipse Packaging Project (EPP). It takes time for major technology changes such as those in the 4.0 release to work their way through such a large development community. We are producing this release so that the developers of other Eclipse projects and plug-ins can adopt it and prepare for a future Eclipse simultaneous release built upon it.

What is the difference between Eclipse SDK 3.6 and 4.0?

Eclipse SDK 3.6 is our contribution to the Helios simultaneous release. It includes a typical set of changes over the previous 3.5 release, and serves as the basis for the entire Eclipse Foundation suite of projects built on top of the core platform. The Eclipse SDK 4.0 has roughly the same features as Eclipse SDK 3.6, but built on entirely new underlying technology. The 4.0 release looks and acts a bit different, but has roughly the same end user features as the 3.6 release.

Why isn't this release in the latest Fedora/Ubuntu/Debian distros?

We have been talking to the maintainers of various Linux distros and are recommending that they do not adopt the Eclipse SDK 4.0 release. Most distros actually contain many Eclipse plug-ins above the base Eclipse platform, and there will be no releases of all those other plug-ins that are developed and tested against the Eclipse SDK 4.0. Look for your favorite Linux distro to incorporate Eclipse SDK 4.x once it is part of a larger Eclipse Foundation simultaneous release and a larger body of third party plug-ins are developed and tested for the 4.0 version of the platform.

For Adopters (Plug-In Developers)

How does Eclipse 4.0 differ from 3.x architecturally?

The Eclipse SDK 4.0, for the most part, contains all the plug-ins that make up Eclipse 3.6. That is, all of JDT and PDE, and most of the Platform, are the same bits as in 3.6. What's different is the implementation of the Workbench, i.e. the org.eclipse.ui.workbench plugin, and the technologies this new implementation is based on. Before the release, the technologies (modeled UI, dependency injection and service-based programming model, CSS-based styling) were called 'e4' but we are now referring to them as the Eclipse 4 Application Platform. On top of the Eclipse 4 Application Platform, the 4.0 Workbench offers an implementation of the 3.x Workbench APIs, to provide backwards compatibility mainly for the Eclipse IDE.

Eclipse 4 Architecture.png

Why Eclipse SDK 4.0?

In 2007, the Eclipse Project leadership decided some major changes were needed in the Eclipse platform. See this EclipseCon 2008 talk for more details on the motivation and thinking behind these changes. It would have been too disruptive to attempt these changes within a single annual release cycle, so a new incubator project was started to run in parallel to normal Eclipse project development. Several pieces of technology from this incubator have since matured and are ready for wider consumption. Some of these changes have already been integrated in the annual Galileo and Helios releases.

For the biggest changes, we want to provide the community all the time it needs to adopt this new technology, so the 4.x stream was created to allow for 3.x and 4.x releases to occur in parallel. For at least 2010 and 2011 there will be parallel 3.x and 4.x stream releases to allow clients to stage their adoption of the new platform technology at their own pace.

Why did you release Eclipse 4.0 one month after Eclipse 3.6?

Many committers work on both 3.x and 4.x, and releasing both versions of the platform at the same time would not allow these committers to devote the time required to get a high quality release out the door on schedule. Also, the 4.x stream depends on technology from other Eclipse Foundation projects that have release dates slightly behind the 3.x platform, so the lag allows us to pick up those dependencies after they have shipped.

Where is the plan for this release?

The Eclipse Project 4.0 plan is available here.

Is this release part of the Helios (2010) release train?

No. Although the 4.0 release is largely compatible with previous Eclipse project releases, implementation details and some of our feature contents have changed. Plug-ins that access internals or rely on implementation details not covered by the API specs will have to be changed to be API clean. It will also take some time for the other release train projects to test their plug-ins and potentially adopt new technology, so generally there is no guarantee that features developed for the Helios release will install or behave correctly in the Eclipse SDK 4.0

Will this release be part of the Indigo (2011) release train?

We plan to create an Eclipse project 4.1 release for the summer of 2011. We would like to see the 4.1 release become the basis for the 2011 simultaneous release, but ultimately the decision will be made by the Eclipse Planning Council that coordinates the foundation's simultaneous releases. The projects that make up the simultaneous release will need to evaluate the Eclipse SDK 4.0 release and decide if they are ready to make that move for the June 2011 release.

For RCP Developers

Will this release make the CDT Indexer better?

No. CDT is not part of the Eclipse Project. It is a separate project with its own releases.


What is e4?

e4 is a sub-project of the Eclipse top-level project. It is an incubator where we can play around with different ideas about the future direction of the platform. It is a place where we can quickly bring in new committers so they can try out their ideas. It is our playground. Some of these ideas will bear fruit and migrate into other mature projects, and others will remain in the incubator. Some work from e4 has migrated into the Helios release, and other parts into the Eclipse SDK 4.0 release.

Who is working on e4?

e4 has active committers from eight companies, as well as a few individual committers. For complete details see the dash diversity report.

What is e4 1.0 and how does it related to Eclipse SDK 4.0?

We had originally intended for all e4 components to participate in a July 2010 release called version 1.0. This was the logical sequel to our July 2009 release version 0.9. However since the e4 project is a perpetual incubator, and the various technologies it contains are at varying levels of completion, we decided that traditional version numbers didn't make sense in this context. We are now simply referring to this release as the e4 July 2010 release.

What is e4 0.9?

e4 0.9 was a technology preview released in July 2009. You can download it from here. All of the technology in the Eclipse SDK 4.0 release was present in the 0.9 release in a more rudimentary form.

What happened to the e4 flexible resources work?

The Resources component of the e4 project was originally created to explore problems with the Eclipse platform's rigid workspace resource model. This work, led by Freescale Semiconductor with contributions from several others, has since matured and has been incorporated to the Eclipse SDK Helios (3.6) release. Since this work resulted in a relatively small set of fully compatible changes to the existing resource model, we decided it was appropriate to release it in our 3.6 minor release rather than waiting for the major 4.0 release.

What happened to the e4 JavaScript debugger work?

We decided that the best long term home for this work was the new JSDT project under the Web Tools top level project. All JavaScript debugger work has been migrated to JSDT and is part of the Helios 2010 simultaneous release.

What happened to SWT Browser Edition?

One of the areas of exploration in e4 0.9 was a new port of the SWT library called SWT Browser Edition (SWT/BE). This effort used cross-compiling technology to allow SWT applications to run on web technologies such as JavaScript/DOJO and ActionScript/Flex. In theory this approach promised the possibility of writing an application once and having it run in both rich client and Web browser environments. This approach worked well for simple applications, but proved unsuccessful for larger and more complex applications. The failure was partly due to the limitations of cross-compilation, but more fundamentally Web applications tend to have quite different user interaction styles and performance characteristics than traditional desktop applications. Applications designed for the desktop simply didn't behave well when cross-compiled and run in the more constrained browser environment. We decided this fundamental approach was a failure, and are instead focusing on the opposite approach: designing and writing applications for the browser and then also running them in a desktop environment. Applications designed for the more limited browser environment tend to behave quite well when run in a browser widget in a traditional desktop application.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.