The Next Eclipse

We've been planning the follow-on feature release to Eclipse 2.1 since last December. In the initial draft 2.2 plan, we sketched in broad strokes an Eclipse 2.2 release to be completed early 1Q2004. As we now begin working on 2.2 in earnest, we're now thinking of being bolder, giving ourselves a bit more time, and calling the next Eclipse release 3.0. This note outlines our thinking, and what these changes would mean.

What's coming in the next Eclipse?

The kinds of changes under consideration for the next release of the Eclipse fall under these general themes:

• Rich client platform. Eclipse was designed as a universal tool integration platform. However, many facets and components of Eclipse are not particularly specific to IDEs and make equal sense in non-IDE applications (e.g., window-based GUI, plug-ins, help system, update manager). Certain changes, like factoring out IDE-specific facilities, would allow the Eclipse Platform to be generalized into a rich client platform for building non-IDE applications.
• User experience. Improving Eclipse from the point of view of the end user. This includes improving both the "out of the box" experience so that new users are productive faster, and finding better ways to scale up to large numbers of plug-ins without overwhelming the user.
• Responsive UI. Making it easier to write Eclipse plug-ins that keep the UI responsive. Areas for improvement run the gamut from the UI becoming sluggish (or temporarily freezing) when blocking operations are done in the UI thread, to long-running operations like builds and searches which could be performed in the background while the user continues to work.
• Extended Java family. Generalize JDT to handle more members of the Java family than just Java source files. This includes widening to handle Java-like languages (such as JSP and JSQL), and embracing non-Java files containing references to Java language elements (such as plug-in manifest files and J2EE deployment descriptors).
• J2SE 1.5 support. Add JDT support for new Java language features coming in J2SE 1.5.

We see an opportunity to realize significant improvements in these areas with the next Eclipse, and are actively exploring possible approaches.

Maintaining vs. breaking compatibility with Eclipse 2.1?

Maintaining compatibility incurs a cost by stifling radical improvements and making it hard to outgrow past mistakes. Breaking compatibility incurs a cost because it generally makes life more difficult for plug-in tool authors and customers alike. Some of the most exciting improvements under consideration are difficult to pursue while maintaining compatibility. For instance, changing Eclipse so that it can be used as a rich-client platform would almost certainly require breaking API changes to decouple the workbench UI from workspace and resources and parcel up workspace-free functionality into new plug-ins. The freedom to break compatibility would give us additional freedom to innovate and make the next Eclipse significantly better than it could have been had we tried to maintain compatibility.

What to call the next release?

We'd planned on calling the next Eclipse "2.2". However, incrementing the minor version number from "2.1" to "2.2" normally suggests compatibility and that existing 2.* plug-ins would run on the new release without change. Given the kinds of breaking changes we might make in the next release, this sets unrealistic expectations. Changing the version number to "3.0" suggests that existing 2.* plug-ins would not work with the 3.0 release, and would need to be ported to 3.0. This is likely closer to where we would end up.

Just how incompatible would the next release be?

We foresee that some of the Eclipse APIs would change in ways that will require rewriting portions of existing plug-ins written to the 2.* APIs. However, most of the Eclipse APIs will be the same in 3.0 as in 2.1. In general, we are satisfied with the state of all Eclipse APIs in 2.1 and have no inclination (or time) to start over. We would only break APIs in 3.0 when have a compelling case for doing so. Some of the ways we would manage things:

• All proposed breaking API changes would be reviewed by the Eclipse development team leads and the Eclipse Project PMC to ensure that there is a sound case for breaking compatibility on certain APIs, and that the breakage is minimized.
• Since breaking API changes can seriously destabilize the development of 3.0, we would plan to make all breaking API changes early in the cycle. By the end of calendar year 2003, all breaking API changes would be in place and tested. This would allow the remainder of the release cycle to proceed without further disruption, and allow existing plug-ins to be ported to the new 3.0 APIs in parallel.
• We would provide a comprehensive Eclipse 3.0 Porting Guide covering all areas where we make breaking API changes, and describing how to port existing 2.1 plug-ins to 3.0. We would include up-to-date drafts of this porting guide with each milestone build, so that it will be possible to climb aboard the 3.0 release wagon at the early stages, or to estimate the amount of effort that will be involved in eventually porting existing plug-ins to 3.0.

What would this mean for products shipping on 2.1?

Eclipse 2.1 is still the most up-to-date stable base for Eclipse plug-ins and products. Regardless of what happens with 2.2/3.0, we will continue to fix significant defects in this code base, and make them available as patches and as periodic 2.1.* maintenance releases.