Eclipse Project
DRAFT 3.2 Plan

Frozen version for the Eclipse Roadmap v1.0, last revised 11:30 EST February 14, 2005 ( marks interesting changes)
The most current version of this document is available on the Platform website.

    Please send comments about this draft plan to the eclipse-dev@eclipse.org developer mailing list.

This document lays out the feature and API set for the next feature release of Eclipse after 3.1, designated release 3.2.

• Release deliverables
• Release milestones
• Target operating environments
• Compatibility with previous releases
• Eclipse Platform project
• Java development tools (JDT) project
• Plug-in development environment (PDE) project

Plans do not materialize out of nowhere, nor are they entirely static. To ensure the planning process is transparent and open to the entire Eclipse community, we (the Eclipse PMC) post plans in an embryonic form and revise them throughout the release cycle.

The first part of the plan deals with the important matters of release deliverables, release milestones, target operating environments, and release-to-release compatibility. These are all things that need to be clear for any release, even if no features were to change. 

The remainder of the plan consists of plan items for the three projects under the Eclipse top-level project. Each plan item covers a feature or API that is to be added to Eclipse, or some aspect of Eclipse that is to be improved. Each plan item has its own entry in the Eclipse bugzilla database, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail.

Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single Platform component; others may involve coordinated changes to several components; other may pervade the entire Platform. Although some plan items are for work that is more pressing that others, the plan items appear in no particular order.

With the previous release as the starting point, this is the plan for how we will enhance and improve it. Fixing bugs, improving test coverage, documentation, examples, performance tuning, usability, etc. are considered routine ongoing maintenance activities and are not included in this plan unless they would also involve a significant change to the API or feature set, or involve a significant amount of work. The intent of the plan is to account for all interesting feature work.

The current status of each plan item is noted:

• Committed plan item - A committed plan item is one that we have decided to address for the release.
• Proposed plan item - A proposed plan item is one that we are considering addressing for the release. Although we are actively investigating it, we are not yet in a position to commit to it, or to say that we won't be able to address it. After due consideration, a proposal will either be committed or deferred.
• Deferred plan item - A reasonable proposal that will not make it in to this release for some reason is marked as deferred with a brief note as to why it was deferred. Deferred plan items may resurface as committed plan items at a later point.

Release deliverables

The release deliverables have the same form as previous releases, namely:

• Source code release for Eclipse Project, available as versions tagged "R3_2" in the Eclipse Project CVS repository.
• Eclipse Project SDK (includes runtime binary and SDK for Platform, JDT, and PDE) (downloadable).
• Eclipse Platform runtime binary and SDK distributions (downloadable).
• Eclipse RCP runtime binary and SDK distributions (downloadable).
• JDT runtime binary and SDK distributions (downloadable).
• PDE runtime binary and SDK distributions (downloadable).
• Eclipse SDK Examples (downloadable).
• SWT distribution (downloadable).

Release milestones

Release milestone occurring at roughly 6 week intervals exist to facilitate coarse-grained planning and staging. The milestones are:

• Friday Aug. 12, 2005 - Milestone 1 (3.2 M1) - stable build
• Friday Sep. 23, 2005 - Milestone 2 (3.2 M2) - stable build
• Friday Nov. 4, 2005 - Milestone 3 (3.2 M3) - stable build
• Friday Dec. 16, 2005 - Milestone 4 (3.2 M4) - stable build

Additional 2006 milestones will be added later. Our target is to complete 3.2 in 2Q2006. All release deliverables will be available for download as soon as the release has been tested and validated in the target operating configurations listed below.

Target Operating Environments

In order to remain current, each Eclipse release targets reasonably current versions of the underlying operating environments.

Most of the Eclipse SDK is "pure" Java™ code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java 2 Platform itself. The 3.2 release of the Eclipse Project is written and compiled against version [TBD] of the Java 2 Platform APIs, and targeted to run on version [TBD] of the Java 2 Runtime Environment, Standard Edition.

There are many different implementations of the Java 2 Platform running atop a variety of operating systems. We focus Eclipse testing on a handful of popular combinations of operating system and Java 2 Platform; these are our reference platforms. Eclipse undoubtedly runs fine in many operating environments beyond the reference platforms we test. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Eclipse on non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Eclipse on a reference platform.

Eclipse SDK 3.2 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):

Although untested, Eclipse should work fine on other OSes that support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated librares (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.

An early access version of Eclipse is also available for 64-bit Linux GTK. Testing has been limited to early access 64-bit J2SEs running on AMD64 processors.

SWT is also supported on the QNX Neutrino operating system, x86 processor, Photon window system, and IBM J9 VM version 2.0. Eclipse 3.2 on Windows or Linux can be used cross develop QNX applications. (Eclipse is unavailable on QNX because there is currently no J2SE for QNX.)

Internationalization

The Eclipse Platform is designed as the basis for internationalized products. The user interface elements provided by the Eclipse SDK components, including dialogs and error messages, are externalized. The English strings are provided as the default resource bundles.

Latin-1 locales are supported by the Eclipse SDK on all of the above operating environments; DBCS locales are supported by the Eclipse SDK on the Windows, GTK, and Motif window systems; BIDI locales are supported by the Eclipse SDK only on Windows operating environments.

The Eclipse SDK supports GB 18030, the new Chinese code page standard, on Windows XP and 2000, and Linux.

German and Japanese locales are tested.

BIDI support

SWT fully supports BIDI on Windows (only). On Linux GTK, SWT supports entering and displaying BIDI text. The widget orientation of JFace windows defaults appropriately in BIDI locales on Windows (only).

The Eclipse SDK is a development environment targeted at technical professionals - not an end user application. However, the Eclipse SDK tools will permit technical professionals who are working in English to build Hebrew/Arabic end user Java programs which are themselves not based on the Eclipse SDK. The BIDI support in the Eclipse SDK allows a Java programmer to work with BIDI strings, code comments, etc. but the Eclipse SDK itself is not designed to be localized for BIDI locales and its widget orientation can not be changed.

Compatibility with Previous Releases

Compatibility of Release 3.2 with 3.1

Eclipse 3.2 will be compatible with Eclipse 3.1 (and, hence, with 3.0).

API Contract Compatibility: Eclipse SDK 3.2 will be upwards contract-compatible with Eclipse SDK 3.1 except in those areas noted in the Eclipse 3.2 Plug-in Migration Guide. Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.2 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.2 APIs would ensure compliance with Eclipse SDK 3.1 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.

Binary (plug-in) Compatibility: Eclipse SDK 3.2 will be upwards binary-compatible with Eclipse SDK 3.1 except in those areas noted in the Eclipse 3.2 Plug-in Migration Guide. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.2 will not be usable in Eclipse SDK 3.1. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 3.2 will be upwards source-compatible with Eclipse SDK 3.1 except in the areas noted in the Eclipse 3.2 Plug-in Migration Guide. This means that source files written to use Eclipse SDK 3.1 APIs might successfully compile and run against Eclipse SDK 3.2 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK APIs, they will not be usable with an earlier version of the Eclipse SDK.

Workspace Compatibility: Eclipse SDK 3.2 will be upwards workspace-compatible with Eclipse SDK 3.1 unless noted. This means that workspaces and projects created with Eclipse SDK 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.2 and upgraded to a 3.2 workspace. This includes both hidden metadata, which is localized to a particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual plug-ins developed for Eclipse SDK 3.2 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.2 plug-in developers are responsible for ensuring that their plug-ins recognize 3.1, 3.0, 2.1, and 2.0 metadata and process it appropriately. User interface session state may be discarded when a workspace is upgraded. Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 3.2 will be unusable with a product based an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.2 will generally be unusable with earlier versions of Eclipse.

Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name, are considered implementation details which may vary between operating environment and are subject to change without notice. Client plug-ins that directly depend on anything other than what is specified in the Eclipse SDK API are inherently unsupportable and receive no guarantees about compatibility within a single release much less with an earlier releases. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Themes and Priorities

The changes under consideration for the next release of Eclipse Platform, JDT, and PDE will address major themes identified by the Eclipse Requirements Council (Themes and Priorities dated Dec. 15, 2004 - pdf). Three of them are especially germane to this top level project:

• Scaling Up - This refers to the need for Eclipse to deal with development and deployment on a larger and more complex scale. Increasing complexities arise from large development teams distributed in different locations, large source code bases and fragile build environments that have been developed incrementally over time, the dynamic nature of new source code bases and their interaction with configuration management, and build environments involving many different tools and build rules.
• Enterprise Ready - Eclipse should be improved to allow it to be better used by large development organizations.
• Design for Extensibility: Be a Better Platform - Within the Eclipse community, many development projects are defining new development platforms on top of the Eclipse Platform. The Eclipse Platform must evolve to better support this type of usage, including providing new common infrastructure and abstraction layers needed by upper platforms and adding APIs to expose existing functionality only available internally so that upper platforms can more readily integrate with and reuse what's already there.

Each of the 3 projects under the Eclipse top-level project is covered in its own section:

• Eclipse Platform project
• Java development tools (JDT) project
• Plug-in development environment (PDE) project

For each project, the items listed reflect new features of Eclipse or areas where existing features will be significantly reworked. Each item indicates the components likely affected by that work item (many items involve coordinated changes to several components). Numbers in parentheses link to bugzilla problem reports for that plan item.

Eclipse Platform project

The Eclipse Platform provides the most fundamental building blocks. Plan items reflect new features of the Eclipse Platform, or areas where existing features will be significantly reworked.

Committed Items (Eclipse Platform project)

None at this time.

Proposed Items (Eclipse Platform project)

None at this time.

Deferred Items (Eclipse Platform project)

None at this time.

(End of items for Eclipse Platform project.)

Java development tools (JDT) project

Java development tools (JDT) implements a Java IDE based on the Eclipse Platform. The following work items reflect new features of JDT, or areas where existing features will be significantly reworked.

Committed Items (Eclipse JDT project,)

None at this time.

Proposed Items (Eclipse JDT project)

None at this time.

Deferred Items (Eclipse JDT project)

None at this time.

(End of items for Eclipse JDT project.)

Plug-in development environment (PDE) project

Committed Items (Eclipse PDE project)

None at this time.

Proposed Items (Eclipse PDE project)

None at this time.

Deferred Items (Eclipse PDE project)

None at this time.

(End of items for Eclipse PDE project.)