Last revised Friday, August 30, 2002
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) are posting 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:
The release deliverables have the same form as previous releases, namely:
Release milestone occurring at roughly monthly intervals exist to facilitate coarse-grained planning and staging. The milestones for the remainder of this year are:
Additional 2003 milestones will be added later. Our target is to complete 2.1 late in 1Q2003. 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.
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.0 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.0 has been 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 for Microsoft Windows |
IBM Developer Kit for Windows, Java 2 Technology Edition, version 1.3.0 | ||
Sun Java 2 SDK, Standard Edition, version 1.4 for Microsoft Windows | ||
Linux | Intel x86 | Sun Java 2 SDK, Standard Edition, version 1.3.1 for Linux x86 |
IBM Developer Kit for Linux, Java 2 Technology Edition, version 1.3.0 | ||
Sun Java 2 SDK, Standard Edition, version 1.4 for Linux x86 | ||
Sun Solaris | SPARC | Sun Java 2 SDK, Standard Edition, version 1.3.1 for Solaris SPARC |
Sun Java 2 SDK, Standard Edition, version 1.4 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.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 2000 | Primary |
Windows XP | 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 |
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 and 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.
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.
It is a given that Eclipse 2.1 will be upwards compatible with Eclipse 2.0. And incompatible break with the past this early on would be both unwelcome and unwarranted.
API Contract Compatibility: The Eclipse SDK 2.1 will be upwards contract-compatible with the Eclipse SDK 2.0 unless noted. This means that programs in full compliance with contracts specified in the Eclipse SDK 2.0 APIs will automatically be in full compliance with the 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 the Eclipse SDK 2.1 APIs would ensure compliance with the Eclipse SDK 2.0 APIs.
Binary (plug-in) Compatibility: The Eclipse SDK 2.1 will be upwards binary-compatible with the Eclipse SDK 2.0 unless noted. This means that plug-ins built for the Eclipse SDK 2.0 will continue to work correctly in the Eclipse SDK 2.1 without change. Downward plug-in compatibility is not supported. Plug-ins for the Eclipse SDK 2.1 are unlikely to be usable in the 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.
Source Compatibility: The Eclipse SDK 2.1 will be upwards source-compatible with the Eclipse SDK 2.0 unless noted. This means that source files written to use the Eclipse SDK 2.0 APIs can be successfully compiled and run against the 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 the 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 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).
Improved Platform startup times. Progress was made to improve 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]
User configurable key bindings. Ability for user to redefine the key bindings for the editor and the menu accelerators. [Platform UI]
Improve support for cheat sheets. A cheat sheet is an instance of a simple kind of workflow support. The Welcome Page editor is a simple example of a cheat sheet. We will provide a standard API for creating cheat sheets. [Platform UI]
None at this time.
None at this time.
None at this time.
(End of items for Eclipse Platform subproject.)
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.
More flexible project layout. Support build output folders that are outside of the workspace.
None at this time.
None at this time.
None at this time.
(End of items for Eclipse JDT subproject.)
None at this time.
None at this time.
None at this time.
None at this time.
(End of items for Eclipse PDE subproject.)