Eclipse4/FAQ
On July 2010, the Eclipse Project scheduled and released a major new version of the Eclipse SDK, versioned 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. With Juno release train, the Eclipse SDK 4.x will form the base of all packages.
This FAQ describes what this new 4.x stream is about, what to expect from it, and who should be interested in it. For questions about development using the Eclipse 4 Application Platform, see the E4AP RCP documentation and its FAQ.
Contents
Eclipse SDK 4.2 Release
General
When was the Eclipse 4.2 SDK released?
The Eclipse SDK 4.2 Release was released to the general public on June 2012.
Who is the target audience for this release?
The audience for this release is anyone that is regularly using an Eclipse 3.x build. Both developers who are building products and plug-ins on top of the Eclipse Platform and end users of Eclipse are encouraged to download and use the Eclipse 4.2 SDK.
For developers in particular, this release provides them with a stable base to test their software against and report any problems in the Eclipse project 4.x 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 4.2 SDK can be downloaded from the Eclipse project download page.
End Users
How do I go back to the 3.x Look and Feel?
Choose the Classic theme on the General > Appearance Preference page.
How do I update the appearance of Eclipse 4.2?
Some of the preferences from the General > Appearance > Colors and Fonts Preference page have been overridden by the themes used in Eclipse 4.2. See CSS for tips on how to edit your CSS.
What are some of the known issues with the Eclipse 4.2 SDK?
Please see Known Issues with the Eclipse 4.2 SDK.
For Adopters (Plug-In Developers)
How does Eclipse 4.x differ from 3.x architecturally?
The Eclipse SDK 4.2, for the most part, contains all the plug-ins that make up Eclipse 3.8. That is, all of JDT and PDE, and most of the Platform, are the same bits as in 3.8. 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 or E4AP. On top of the Eclipse 4 Application Platform, the 4.2 Workbench offers an implementation of the 3.x Workbench APIs, to provide backwards compatibility mainly for the Eclipse IDE.
Why Eclipse SDK 4.x?
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 Helios and Indigo 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.
Is this release a part of the Juno (2012) release train?
Yes, Eclipse 4.2 is part of Juno and the EPP projects are based on Eclipse 4.2. Eclipse 3.8 will be released at the same time as Juno, but won't be in the release train.
Eclipse SDK 4.1 Release
General
When was the Eclipse 4.1 SDK released?
The Eclipse SDK 4.1 Release was released to the general public on June 2011.
Is the 4.1 SDK an "Early Adopter" release like the 4.0 SDK was?
The "Early Adopter" moniker was dropped for this release and it is treated as a full mature release of the Eclipse Platform. This release has made great progress in robustness and compatibility from the previous release, and is starting to exploit some of the power and flexibility of the new modeled UI and declarative styling support introduced with the 4.0 release. However, this release is not yet ready for enterprise level adoption. There are still improvements to be made in accessibility and usability before this stream completely replaces the 3.x platform generation.
Who is the target audience for this release?
The audience for this release is anyone that is regularly using an Eclipse 3.x build. Both developers who are building products and plug-ins on top of the Eclipse Platform and end users of Eclipse are encouraged to download and try the Eclipse 4.1 SDK.
For developers in particular, this release provides them with a stable base to test their software against and report any problems in the Eclipse project 4.x 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 4.1 SDK can be downloaded from from this location.
End Users
What are some of the known issues with the Eclipse 4.1 SDK?
Please see Eclipse4.1/KnownIssues.
For Adopters (Plug-In Developers)
Is this release a part of the Indigo (2011) release train?
While the Eclipse 4.1 SDK was released to the general public at the same time as the Indigo release train, none of the EPP packages were built on top of the Eclipse 4.1 SDK.
Eclipse SDK 4.0 Early Adopter Release
General
Where can I download it?
The Eclipse SDK 4.0 early adopter release is available here.
For End Users
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.
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.
For Adopters (Plug-In Developers)
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
Why are the org.eclipse.e4.ui.workbench.UIEvents.buildTopic() methods deprecated in 4.2 M4
We have come up with a simpler and more efficient way to subscribe to E4 events. For a discussion of the E4 UI event model look here. For a discussion of migrating from the old buildTopic style to the new style look here.
e4
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.
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/Debug 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.