Eclipse Project
DRAFT 2.1 Plan

Last revised Tuesday, December 3, 2002 ( marks interesting changes since the previous draft of Oct. 11)

    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, designated release 2.1.

Plans do not materialize out of nowhere, nor are they entirely static. To make the planning process more transparent and open to the Eclipse community, we (the Eclipse PMC) posted the plan in an embryonic form and are revising it 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 various Eclipse subprojects. 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 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 details (which can be hashed out elsewhere). 

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.

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, 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. All interesting feature work is accounted for in this plan.

The current status of each plan item is noted:

• Proposed plan item - A proposal for an aspect to work on for the release. After due consideration, a proposal will either be committed, rejected, or deferred.
• Committed plan item - A committed plan item is one that we have decided to address for the release.
• Deferred plan item - A reasonable proposal that did not make it in to this release for some reason is marked as deferred with a brief note as to why they were deferred. Deferred plan items may resurface as proposed plan items at a later point.
• Rejected plan item - Plan items that were proposed but judged unworkable are marked as rejected plan items, with an accompanying summary of why they were dismissed. Keeping track of rejected items avoids repeating the discussion.

Release deliverables

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

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

Release milestones

Release milestone occurring at roughly monthly intervals exist to facilitate coarse-grained planning and staging. The milestones for this release are:

• September 20, 2002 - Milestone 1 - (2.1 M1) - stable build reflecting progress
• October 18, 2002 - Milestone 2 - (2.1 M2) - stable build reflecting progress
• November 15, 2002 - Milestone 3 - (2.1 M3) - stable build reflecting progress
• December 13, 2002 [delayed to December 18] - Milestone 4 - (2.1 M4) - stable build reflecting progress
• February 7, 2003 - Milestone 5 - (2.1 M5) - stable build - feature complete - development freeze - lock down and testing begins

(Note that the last milestone is extended to allow for vacations over the holiday season.)

The 2.1 release is targeted for March 2003. 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 2.1 release of the Eclipse Project is written and compiled against version 1.3 of the Java 2 Platform APIs, and targeted to run on either version 1.3 or 1.4 of the Java 2 Runtime Environment, Standard Edition.

Eclipse SDK 2.1 will be tested and validated on the following Java 2 Platform implementations:

Operating system	Processor architecture	Java 2 Platforms
Microsoft® Windows®	Intel x86	Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for Microsoft Windows
		Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for Microsoft Windows
		IBM Developer Kit for Windows, Java 2 Technology Edition, version 1.3.1 SR-1
		IBM 32-bit SDK for Windows, Java 2 Technology Edition, version 1.4.0
Linux	Intel x86	Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for Linux x86
		Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for Linux x86
		IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.3.1 SR-1
Sun Solaris	SPARC	Sun Java 2 SDK, Standard Edition, version 1.3.1_06 for Solaris SPARC
		Sun Java 2 SDK, Standard Edition, version 1.4.1_01 for Solaris SPARC
HP HP-UX	hp9000 PA-RISC	HP-UX SDK for the Java 2 platform, version 1.3.1 for hp9000 PA-RISC
IBM® AIX	PowerPC	IBM Developer Kit for AIX, Java 2 Technology Edition, version 1.3.1
Apple® Mac® OS	PowerPC	Java 2 Standard Edition 1.3.1 for Mac OS X 10.2
QNX® Neutrino® RTOS	Intel x86	IBM J9 VM for QNX, version 2.0

The following table describes the combinations of operating system and Java 2 Platform used when testing the Eclipse SDK configurations. The status column indicates the level of testing: "Primary" means a full tested configuration; "Secondary" means a configuration which is only lightly tested; "Untested" means a configuration that has received no testing, but which should work.

Window system	Java 2 Platform (see above table)	Operating Environment	Testing Status
Win32	Windows on Intel x86	Windows XP	Primary
		Windows 2000	Primary
		Windows ME	Secondary
		Windows 98SE	Secondary
		Windows NT	Secondary
Motif	Linux on Intel x86	RedHat Linux 7.2 x86	Primary
		SuSE Linux 7.3 x86	Primary
		Other Linux; kernel version 2.4.7, and XFree86 version 4.1.0	Untested
	Solaris on SPARC	Sun Solaris 8 SPARC	Primary
	HP-UX on hp9000 PA-RISC	HP-UX 11i hp9000	Primary
	AIX on PowerPC	IBM AIX 5.1 on PowerPC	Primary
GTK	Linux on Intel x86
		RedHat Linux 7.2 x86 GTK 2.0	Primary
		SuSE Linux 7.3 x86 GTK 2.0	Primary
		Other Linux; kernel version 2.4.7, and GTK 2.0	Untested
Carbon	Mac OS X on PowerPC	Mac OS X 10.2	Early access
Photon®	IBM J9 VM for QNX	QNX Neutrino RTOS 6.2.1	Primary

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 2000 and XP only. Note that GB 18030 also requires locale and character encoding support from the Java 2 Runtime Environment; this support is standard in version 1.4, and also available in some 1.3 JREs.

German and Japanese locales have been tested.

BIDI support

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.

IMPORTANT: The above BIDI support is available only on Windows platforms.

Compatibility with Previous Releases

It is a given that Eclipse 2.1 will be upwards compatible with Eclipse 2.0. An incompatible break with the past this early on would be both unwelcome and unwarranted.

Compatibility of Release 2.1 with 2.0

API Contract Compatibility: Eclipse SDK 2.1 will be upwards contract-compatible with Eclipse SDK 2.0 unless noted. This means that programs in full compliance with contracts specified in Eclipse SDK 2.0 APIs will automatically be in full compliance with Eclipse SDK 2.1 APIs. (API is construed broadly to include such things as plug-in extension points.) Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 2.1 APIs would ensure compliance with Eclipse SDK 2.0 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 2.1 will be upwards binary-compatible with Eclipse SDK 2.0 unless noted. This means that plug-ins built for Eclipse SDK 2.0 will continue to work correctly in Eclipse SDK 2.1 without change. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 2.1 are unlikely to be usable in Eclipse SDK 2.0. Plug-ins with hard-coded references in their plug-in manifest file to 2.0 versions of prerequisite Eclipse Project plug-ins will work in 2.1 provided the version match rule is "greaterOrEqual" or "compatible" (the default); references using "perfect" or "equivalent" match rules will be broken. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.

Source Compatibility: Eclipse SDK 2.1 will be upwards source-compatible with Eclipse SDK 2.0 unless noted. This means that source files written to use Eclipse SDK 2.0 APIs can be successfully compiled and run against Eclipse SDK 2.1 APIs. Since source incompatibilities are easy to deal with, maintaining source compatibility is considered much less important than maintaining contract and binary compatibility. Downward source compatibility is not supported. If source files use new Eclipse SDK APIs, they will not be usable with an earlier version of Eclipse SDK.

Workspace Compatibility: Eclipse SDK 2.1 will be upwards workspace-compatible with Eclipse SDK 2.0 unless noted. This means that workspaces and projects created with Eclipse SDK 2.0 can be successfully opened by Eclipse SDK 2.1 and upgraded to a 2.1 workspace. Individual plug-ins developed for Eclipse SDK 2.0 should provide similar upwards compatibility for their workspace metadata; plug-in developers are responsible for ensuring that their plug-ins recognize 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 Eclipse SDK 2.1 will be unusable with an earlier version of Eclipse SDK.  

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 release. Refer to How to Use the Eclipse API for information about how to write compliant plug-ins.

Eclipse Project Subprojects

Eclipse Platform
JDT - Java development tooling
PDE - Plug-in development environment

For each subproject, the items listed reflect new features of the Eclipse Platform, or areas where existing features will be significantly reworked. Each item indicates the components affected by that work item (many items involve coordinated changes to several components).

Eclipse Platform subproject

Committed Items (Eclipse Platform subproject)

Improve startup time.  Progress was made at improving startup times in 2.0; however, additional improvements are needed. In addition, we need to investigate deferring (or partially omitting) the recovery of the UI state. [Platform Core, Platform UI]

Allow user customizable key bindings.  Eclipse 2.0 supports configurable key bindings, but only for editor key bindings, and only configured by a plug-in. The user should be able to interactively customize the key bindings for all workbench actions. There are additional customization possibilities including visible actions and perspective layout. [Platform UI, SWT, Text, JDT UI]

Improve update manager. Make continuing improvements to the Eclipse install and update mechanisms. Improve support for installing and updating large products making use of nested features. Make remote connections more configurable ( connection using a proxy server behind firewall and authentication) and more robust (time outs). [Platform Core, Platform Install/Update]

Enable DBCS on Linux. Support double-byte characters on the GTK and Motif window systems. [SWT]

Add workbench editor navigation history. The user should be able to navigate between workbench editors with web style back/forward actions. (Ref: bug 5700)  [Platform UI]

( recently committed) Improve Ant support. Add support to navigate from Ant error output to the corresponding source. [Platform UI, Ant Core]

Proposed Items (Eclipse Platform subproject)

Improve serviceability. Progress was made at improving serviceability in 2.0; however, additional improvements are needed, particularly in dealing with error conditions and reporting them in an appropriate manner. [Platform Core, SWT, Platform UI]

Improve file encoding support. Eclipse 2.0 uses a single global file encoding setting for reading and writing files in the workspace. This is problematic; for example, when Java source files in the workspace use OS default file encoding while XML files in the workspace use UTF-8 file encoding. The Platform should support non-uniform file encodings. (Ref: bug 5399) [Platform Core, Platform UI, Text, Search, Compare, JDT UI, JDT Core]

Improve SWT support for right-to-left languages. Allow the appropriate widget orientation for right-to-left languages. [SWT]

Deferred Items (Eclipse Platform subproject)

( recently deferred) Add cheat sheets.  A cheat sheet is an instance of a simple kind of workflow support used to help the user carry out a sequence of steps. For example, "create and deploy a plug-in" is a multi-step process that could be made easier to follow if there was a guide, similar to a recipe that would track the user's progress and provide both descriptive text that explains the steps involved and integration with Eclipse to automate the process. The Welcome Page editor is a simple example of a cheat sheet. Provide a standard API for creating cheat sheets. [Platform UI]

( recently deferred) Add table of contents support to wizards. Extend the workbench wizard framework to allow Eclipse wizard developers to provide much more substantial and significant user feedback. [Platform UI]

( recently deferred) Support floating toolbars and views. Allow the user to customize the workbench by creating floating toolbars and views. [Platform UI]

( recently deferred) Allow editors to open files outside workspace. A common request is to be able to open a file that is not part of the workspace using Eclipse. In addition, applications would like to provide file extension associations so that double-clicking on a file in the OS desktop would open the associated Eclipse editor. The operations and capabilities available on these "outside of the workspace" files would need to be defined. [Platform UI]

Rejected Items (Eclipse Platform subproject)

None at this time.

(End of items for Eclipse Platform subproject.)

Java development tooling (JDT) subproject

Committed Items (Eclipse JDT subproject)

Support building projects with circular dependencies.  Some users are experiencing difficulty partitioning their work into independently-buildable projects. We want to add a mechanism to allow mutually dependent projects to be built successfully, while preserving current project build order behavior. (Ref: bug 10262) [JDT Core, Platform Core]

More flexible project layout.  Support source and output folders that are outside of the workspace. This likely requires Platform Core support so that changes to these folders can be reflected in resource deltas. [JDT Core, JDT UI, Platform Core, Platform UI, Team]

Support multi-JAR system libraries. Some JREs (including Mac OS X and IBM 1.4) package  the Java system class libraries in several JAR files. Improve support for system class libraries so that it is more convenient to develop and run against them. [JDT Core, JDT UI]

Add new refactorings. Support additional refactoring actions, including extract interface, and extract constant. [JDT Core, JDT UI]

Proposed Items (Eclipse JDT subproject)

None at this time.

Deferred Items (Eclipse JDT subproject)

None at this time.

Rejected Items (Eclipse JDT subproject)

None at this time.

(End of items for Eclipse JDT subproject.)

Plug-in development environment (PDE) subproject

Committed Items (Eclipse PDE subproject)

None at this time.

Proposed Items (Eclipse PDE subproject)

Improve build class path for plug-in projects. Plug-ins that make direct reference to JAR libraries of prerequisite plug-ins are vulnerable to version ids in plug-in embedded in directory names. The alternative, using binary library plug-ins for each prerequisite plug-in, leads to a profusion of projects in the workspace. PDE will offer a third alternative based on JDT class path containers that avoids these shortcomings and interoperates with existing plug-in projects.

Add support for update sites. Setting up an Eclipse update site and building its plug-ins and features is not straightforward. PDE will make it convenient to define the layout of an update site and create the update site's contents.

Improve usability. F1 help for all PDE dialogs; improved PDE form editors; improved plug-in manifest editor Extensions page; more user-friendly support for building plug-ins and features.

Add template API. API for PDE template wizards will be defined, allowing other plug-ins to contribute templates for their extension points.

Deferred Items (Eclipse PDE subproject)

None at this time.

Rejected Items (Eclipse PDE subproject)

None at this time.

(End of items for Eclipse PDE subproject.)