The Eclipse Project 3.2 Plan (Final)

Last revised 9:00 EST September 11, 2006 ((new) marks interesting changes since the previous draft of May 9, 2006)

    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 the Eclipse SDK after 3.1, designated release 3.2.

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 Project 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 four projects under the top level Eclipse Project. Each plan item covers a feature or API that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project 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 component; others may involve coordinated changes to several components; other may pervade the entire SDK. Although some plan items are for work that is more pressing than 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:

Release deliverables

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

Release milestones

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

Our target is to complete 3.2 in late June 2006. 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 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 Platform itself. Portions of the Eclipse SDK (including the RCP base, SWT, OSGi and JDT core plug-ins) are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.). With the exception of a small set of planned features that actually require Java SE 5 APIs (most notably, the support for Annotation Processing and JUnit 4), the 3.2 release of the Eclipse Project is developed against version 1.4 of the Java 2 Platform. As such, the Eclipse Project SDK as a whole is targeted at both 1.4 and Java5 VMs, with full functionality available for 1.4 level development everywhere, and new Java5 specific capabilities available when running on a Java5 VM. Appendix 1 contains a table that indicates the class library level required for each plug-in.

There are many different implementations of the Java Platform running atop a variety of operating systems. We focus Eclipse SDK testing on a handful of popular combinations of operating system and Java 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 a 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.

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

Eclipse Reference Platforms
Operating system OS version Processor architecture Window system Java 2 Platform
Microsoft Windows XP Intel x86 Win32 Sun Java 2 Standard Edition 5.0 Update 6
for Microsoft Windows
Microsoft Windows XP Intel x86 Win32 IBM 32-bit SDK for Windows,
Java 2 Technology Edition 5.0 service release 1
Microsoft Windows XP Intel x86 Win32 (new)BEA JRockit 5.0 R26.4,
for Microsoft Windows
Microsoft Windows XP Intel x86 Win32 Sun Java 2 Standard Edition 1.4.2_10
for Microsoft Windows
Microsoft Windows XP Intel x86 Win32 IBM 32-bit SDK for Windows,
Java 2 Technology Edition 1.4.2 service release 3
Microsoft Windows XP Intel x86 Win32 (new)BEA JRockit 1.4.2 R26.4,
for Microsoft Windows
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 1.4.2_10
for Linux x86
Red Hat Enterprise Linux WS 4 Intel x86 GTK IBM 32-bit SDK for Linux on Intel architecture,
Java 2 Technology Edition 1.4.2 service release 3
Red Hat Enterprise Linux WS 4 Intel x86 GTK Sun Java 2 Standard Edition 5.0 Update 6
for Linux x86
Red Hat Enterprise Linux WS 4 Intel x86 GTK IBM 32-bit SDK for Linux on Intel architecture,
Java 2 Technology Edition 5.0 service release 1
SUSE Linux Enterprise Server 9 Intel x86 GTK Sun Java 2 Standard Edition 1.4.2_10
for Linux x86
SUSE Linux Enterprise Server 9 Intel x86 GTK IBM 32-bit SDK for Linux on Intel architecture,
Java 2 Technology Edition 1.4.2 service release 3
Sun Solaris 10 SPARC GTK Sun Java 2 Standard Edition 1.4.2_10
for Solaris SPARC
HP HP-UX 11i hp9000
PA-RISC
Motif HP-UX JDK for the Java 2 Platform Standard Edition for 1.4.2_09
IBM AIX 5L 5.2 Power Motif IBM 32-bit SDK for AIX,
Java 2 Technology Edition 1.4.2 service release 3
Apple Mac OS X 10.4 Power, Intel x86 Carbon Java 2 Platform Standard Edition (J2SE) 1.4.2
service release 2 for Tiger
Red Hat Enterprise Linux WS 4 Power GTK IBM 32-bit SDK for Linux on pSeries architecture,
Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server 9 Power GTK IBM 32-bit SDK for Linux on pSeries architecture,
Java 2 Technology Edition 1.4.2 service release 3
SUSE Linux Enterprise Server 9 Power GTK IBM 32-bit SDK for Linux on pSeries architecture,
Java 2 Technology Edition 1.4.2 service release 3

Because Java 1.4.2 platforms are used for most Eclipse development, in general, 1.4.2 platforms are listed here. Of course, the teams doing Java 5 based development are using Java 5 platforms, and the specific ones that they test on are also included. We expect that Eclipse will work fine on other Java 5 VMs running on window systems supported by SWT, but can not flag these as reference platforms without significant community support for testing them.

Similarly, although untested, the Eclipse SDK 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 libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2. People interested in other configurations, such as Motif on Solaris, should investigate building from source.

An early access version of the Eclipse SDK is also available for 64-bit Linux GTK. Testing has been limited to early access 64-bit J2SEs running on x86-64 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 to cross-develop QNX applications. (Eclipse 3.2 is unavailable on QNX because there is currently no 1.4 J2SE for QNX.)

Internationalization

The Eclipse SDK 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 (level 1), the Chinese code page standard, on Windows XP and 2000, and Linux/GTK.

German and Japanese locales are tested.

BIDI support

SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering and displaying BIDI text. Within these limitations, the Eclipse SDK tools are BIDI enabled.

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 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, PDE and Equinox will address major themes identified by the Eclipse Requirements Council (Themes and Priorities dated Dec. 15, 2004 - pdf). The following are especially germane to this top level project:

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

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)

Support logical model integration. The Eclipse Platform supports a strong physical view of projects containing resources (files and folders) in the workspace. However, there are many situations where plug-in developers would prefer to work with a logical model that is appropriate to their domain. Eclipse should ease the task for plug-in developers who want to make logical model-aware plug-ins. To do this, Eclipse should provide more flexible mechanisms for contributing actions on models that do not have a one-to-one mapping to files on the users hard disk. This would, for example, allow a team provider's repository operations to be made available on logical artifacts. In addition, existing views like the navigator and problems view should be generalized to handle logical artifacts and, in general, there should be better control over what is displayed in views and editors based on the logical models that the end user is working on. [Resources, UI, Team] (37723) [Theme: Design for Extensibility] Work completed

Provide more flexible workspaces. Currently in Eclipse there is a direct connection between IResources and files and directories on the local file system. Eclipse should loosen this connection, by abstracting out its dependency on java.io.File, and allowing for alternative implementations. This would enable, for example, uses where the workspace is located on a remote server, or accessed via a non-file-based API, or has a non-trivial mapping between the resources and the physical layout of the files. [Resources, Text, UI] (106176) [Theme: Design for Extensibility, Enterprise Ready] Work completed

Improve and extend the SWT widget set. Modern UI design is a constantly moving target. SWT should provide the tools needed to implement first class user interfaces. For example: sort indicators in SWT tables; improved coolbar behavior/appearance; and new controls such as collapsible groups. [SWT] (106182) [Theme: Design for Extensibility, Appealing to the Broader Community] Work completed

Address new window system capabilities. SWT's basis in native widgets is one of Eclipse's major strengths. For this to remain true, SWT must continue to grow to encompass new mainstream desktop platforms and new capabilities added to existing platforms. For the 3.2 release, SWT should provide support for Windows Vista. [SWT] (106184) [Theme: Appealing to the Broader Community] Work completed

Enhance the text editor. The Eclipse Text component provides a powerful editing framework that is useful in many contexts, but some of its capabilities are currently only available in the Java editor. The Java editor should be opened up to allow more general access to the reconciling, code assist, and template proposal mechanisms. Another enhancement to the look and feel of the editor is to show change history and comments in the editor. Other possible enhancements include improving the Find/Replace dialog and annotation roll-overs. [Text] (106194) [Theme: Design for Extensibility] Work completed

Improve task assistance in text fields. Eclipse has numerous wizards and dialogs that contain text fields where there are constraints on the values that can be entered, and often task assistance can be provided, for example, in the form of potential values. Eclipse should provide an enhanced text field that has indicators for required fields, and content assist. [UI] (106199) [Theme: Simple to Use] Work completed

Enhance the debug platform. The debug support in Eclipse is increasingly being used in areas that require more flexible mechanisms than those required by simple Java programs. Features will be provided as provisional API subject to change in a future release. Features include: a flexible element hierarchy in debug views to account for different architectures such as multi-core processors, thousands of threads, etc; asynchronous, cancellable interactions when retrieving view content and labels; model driven view updates; a debug context service allowing for retargettable debug actions, flexible view wiring and pluggable source lookup. [Debug] (106205) [Theme: Design for Extensibility, Enterprise Ready] Work completed

Provide a more customizable UI. Products often need direct control over the presence and arrangement of UI elements. Similarly, end users expect to be able to customize the UI to better match their workflow. Eclipse should enable both products and end users to have more control over the user interface. For example, the workbench layout should be made more flexible and configurable, and there should be a framework to allow better control over the presence and ordering of menu and toolbar items. [UI] (106189) [Theme: Simple to Use] Work completed

Capabilities/Perspectives/Components. The UI component has several frameworks for customizing the presentation, filtering the set of available options and supporting task-based UIs tailored to the user's role. This support should be rationalized and better documented. [UI] (80130) [Theme: Simple to Use] Work completed

Provide more support for large scale workspaces. In some situations, users have workspaces containing hundreds of projects and hundreds of thousands of files. Scoped builds and working sets have become important tools for these users, and the performance optimizations done in Eclipse 3.1 have proven helpful. Eclipse should have even more support for dealing with very large workspaces, including improved searching, filtering, working sets, and bookmarks. This goes hand-in-hand with ongoing work to discover and address performance issues. [UI, Resources] (106192) [Theme: Scaling Up, Enterprise Ready] Work completed

Update Enhancements. As the number and range of Eclipse plug-ins continues to grow, it becomes increasingly important to have a powerful update/install story. For instance, if more information about an Eclipse install was available earlier, it would be possible to pre-validate that it would be a compatible location to install particular new features and plug-ins. This information could also be used to deal with conflicting contributions. Update should also be improved to reduce the volume of data that is transferred for a given update, and PDE should provide better tools for creating and deploying updates. [Update, Runtime, PDE] (106185) [Theme: Enterprise Ready] Work completed

Help System enhancements. Enhance the existing Help System functionality in several ways, including support for navigation bread crumbs, support for remote installation of Help documentation, documentation index, more extensible dynamic help view, and various other enhancements. [UA] (114243) [Theme: Design for Extensibility] Work completed

Improve cheat sheet support. The Eclipse cheat sheet infrastructure was implemented 3.0, but is still not widely used. For cheat sheets to be become more widely adopted, the base support should be enhanced in several ways, including: adding support for invoking commands without the need for Java programming; make cheat sheets more scalable; providing for nonlinear dependancy between steps and enhancing the implementation to support working with modal dialogs. [UA, UI] (106196) [Theme: Simple to Use, Design for Extensibility] Work completed

Support dynamic and reusable content in User Assistance components. In previous releases, Eclipse Help manipulated content as a reference. Although the representation is simple and reliable, it is difficult to tailor the content for multiple presentations, or to provide incremental content contributions, content reuse, content filtering etc. The representation for help content should be improved. Also, branding information should be separated from the rest of the content to simplify aggregating multiple contributions into larger units. These features also apply to Welcome, CheatSheets and the dynamic help view. [UA] (106201) [Theme: Design for Extensibility] Work completed

Create Universal Welcome. Since Eclipse 3.0, it is possible to create a powerful Welcome using the provided framework support. In the increasingly componentized environment, it is more and more impractical to create extensions for separate implementations in different products. Based on experience gained in creating Welcome implementations so far, a universal Welcome implementation will be provided that can be shared between many products. Universal Welcome will be customizable by both products and users, and will provide for intelligent merging of content in root pages. A selected number of root pages that can cover the needs of most products will be available. [UA] (127842) [Theme: Simple to Use, Design for Extensibility] Work completed

Deliver support for ICU4J with the Eclipse Platform. Quality internationalization is very important in the modern software world. The ability to fully enable products and applications for double-byte and bi-directional languages is a requirement of any software platform. ICU4J (http://icu.sourceforge.net/) resolves many of the known issues with internationalization for Java, and thus adopting ICU4J will provide the Eclipse Platform with the strong internationalization support it needs to make Eclipse-based applications competitive. The first goal of this work is to make any required porting effort as minimal and straight forward as possible. In addition, we will ensure that applications that must run in constrained environments (such as embedded RCP applications) will not pay a footprint penalty if they do not need full internationalization flexibility. [All] (127876) [Theme: Design for Extensibility, Enterprise Ready] Work completed

Proposed Items (Eclipse Platform project)

None at this time.

Deferred Items (Eclipse Platform project)

Embedding editors and views. Various problems are encountered when trying to embed editors or views within other workbench parts. For example, the current compare infrastructure requires creating a separate text editor for viewing changes between files. This is due to a limitation in the workbench that prevents editors from being embedded inside views or other controls. As a consequence, the compare editor's nested editors don't support the full set of features provided by the corresponding real content-type-specific editor. This represents a major usability problem: the user must switch to the real editor to make changes and then return to the compare view to review the changes. Eclipse should be more flexible in the ways various editors can be used and reused. The UI component model should be improved to support nesting of workbench parts, and reduce the coupling of parts to particular locations in the workbench, allowing for more flexible UI configurations. [UI, Compare, Text] (71125) [Theme: Design for Extensibility]

Improve UI Forms. UI Forms are increasingly being used in the Eclipse user interface. The UI Form support should be improved to allow for more pervasive use in 3.2. Critical widget functionality should be moved to SWT to ensure quality and native look and feel. The remaining UI Forms code (minus FormEditor) should be pushed down into JFace so that it is available in the Eclipse workbench. [SWT, UI, UA] (106203) [Theme: Simple to Use, Design for Extensibility]

Provide a single user-assistance content delivery mechanism. In Eclipse 3.1, three different user-assistance vehicles are used to help users in various contexts: the initial user experience shows the 'Welcome' content; cheat sheets assist during long tasks; Help shows the traditional help topics. These vehicles use similar concepts but have separate/duplicate code bases. They should be reworked so that a single content delivery mechanism is used in various contexts, allowing content producers to benefit from a single way of contributing content, making all the content searchable, and making it presentable in various contexts. This should also take into account whether content is local or remote. [UA] (106200) [Theme: Design for Extensibility]

Improve serviceability. When an end user encounters a problem with Eclipse, it is important for support teams to be able to diagnose the root cause of the failure, and identify the failing plug-in. Eclipse should have enhanced error reporting tools that make it easy for end users to report problems. Tools should be available at all times, so that knowledgeable users could diagnose unexpected behavior such as slowdowns or exceptional memory use. [Runtime, UI, SWT] (106193) [Theme: Simple to Use, Enterprise Ready]

Support GB18030-2. The GB18030-2 Chinese character set is becoming increasingly important in the Java community. Eclipse should support GB18030-2 on platforms where it is supported natively. Because of the fundamental and far reaching impact of implementing this support, it is expected that it will require an SDK (and indeed entire Eclipse Foundation) wide strategy. [All] (127864) [Theme: Simple to Use, Enterprise Ready]

Increase flexibility when building RCP applications. The Eclipse text editor should better support RCP applications, by making features like the following available to them: annotation presentation and navigation, user assigned colors and fonts, spell checking, folding, quick diff, templates, and file buffers. The Eclipse workbench layout should be further opened up to allow RCP applications to have more control over its presentation. [Text, UI] (106187) [Theme: Rich Client Platform]

Provide pervasive user-assistance search capabilities. An important element of the user-assistance support in Eclipse is the federated help search support that was added in R3.1. This support should be expanded to pull in more useful results from various sources. It should also be made more extensible to assist other information contributors, and made more pervasive in the UI. [UA] (106198) [Theme: Simple to Use]

Additional debug platform enhancements. The debug support in Eclipse is increasingly being used in areas that require more flexible mechanisms than those required by simple Java programs. Additional work areas include: the introduction of table trees in standard debug views for better/flexible presentation; drag and drop between all debug views; support for incremental content retrieval and virtual trees; asynchronous table view with pluggable cell editors; and multiple debug scopes/contexts to support simultaneous debugging of different applications side-by-side in different sets of debug views. [Debug] (127874) [Theme: Design for Extensibility, Enterprise Ready]

(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,)

Add support for Java SE 6 features. Java SE 6 (aka "Mustang") will likely contain improvements to javadoc tags (like @category), classfile specification updates, pluggable annotation processing APIs, and new compiler APIs, all of which will require specific support. [JDT Core, JDT UI, JDT Text, JDT Debug] (106206) [Theme: Appealing to the Broader Community] Work completed

Improve NLS tooling. The Eclipse NLS tooling should better support the new Eclipse string externalization pattern added in 3.1. [JDT Text] (106210) [Theme: Simple to use, Scaling up] Work completed

Split refactoring. Refactoring currently relies on a closed world assumption. This means that all of the code to be refactored must be available in the workspace when the refactoring is triggered. However for large distributed teams, the closed world approach isn't really feasible. The same is true for clients which use binary versions of libraries where API changes from one version to another. In 3.2 the closed world assumptions will be relaxed in such a way that a refactoring executed in workspace A can be "reapplied" on workspace B to refactor any remaining references to the refactored element. [JDT Core/UI] (106207) [Theme: Scaling Up] Work completed

Enable compiler participation. JDT compilation technology will be opened to enable pluggable participation.Compilation takes place in various stages, such as building and editor reconciling. A participant will be able to introspect the Java code using DOM/AST API, perform semantic analysis, issue some markers and possibly generate new source files. [JDT Core, JDT UI, JDT Text] (127885) [Theme: Multi-Language Support, Enterprise Ready, Design for Extensibility] Work completed

More static analysis. Code quality can be further improved by new advanced configurable compiler diagnostics, available either when building or when editing Java files. The compiler will conduct some null reference analysis in order to anticipate some NullPointerException at runtime. For cleaning up code, the compiler will detect obsolete $NON-NLS$ tags and unused break/continue label. Assigning a parameter will be configurable as a poor coding style. For assisting migrating existing code to Java 5.0, the compiler will optionally signal any reference to a raw type, not only unchecked ones. Additionally, users will be able to configure optional errors as being non fatal, and thus allow valid classfile generations. [JDT Core] (127887) [Theme: Appealing to the Broader Community] Work completed

Code style clean ups. We will provide new functionality to easily establish project wide code conventions. The 'Clean up' action will take a set of files as input to analyze and offer to fix multiple code style issues at once. Examples of 'clean up' actions are the removal of unnecessary code or qualify all field accesses with 'this'; or assisting migration to Java 5.0 [JDT UI] (127888) [Theme: Simple To Use] Work completed

Improve JUnit support. The JUnit view will be improved to manage more than one set of results. This will allow running multiple tests simultaneously and keep a history of test results. We will also investigate to support JUnit4 which will require the use of J2SE 5.0 in Eclipse itself. [JDT UI] (127889) [Theme: Simple To Use] Work completed

Support arbitrary Java content types. Add support for compilation units with extension different than ".java". This will for example allow components like AJDT to seamlessly integrate their AspectJ ".aj" files into the Java tooling. Existing assumptions on ".java" extensions will be removed throughout the tools. [JDT UI, JDT Core, JDT Debug] (127891) [Theme: Design for Extensibility: Be a Better Platform] Work completed

More refactorings. Various enhancements for existing refactorings including hierarchical package rename and delete, updating related fields, methods and locals on type rename and improved visibility adjustments on move refactorings will be implemented. Furthermore, existing refactorings will be improved to preserve API compatibility where possible (for example when renaming a method, a deprecated stub with the old signature will be generated that forwards to the new method). We will investigate in a new refactoring 'Extract super class'. [JDT UI] (127892) [Theme: Simple To Use] Work completed

Improve user experience in presence of syntax errors. While editing code, all Java tools need to manipulate incomplete sources, containing many syntax errors. Though the structure of the units is usually well extracted (as demonstrated in outline view), power tooling is requiring more than just structural information; many advanced functionalities are requiring a detailed DOM AST to conduct syntax colouring, action enabling, problem highlighting, formatting, etc... New strategies will be explored to recover statements and expressions from incomplete programs and still enable creating detailed DOM AST carrying resolved binding information. All tooling will need to be calibrated to properly handle detailed recovered DOM AST. [JDT Core, JDT UI] (127895) [Theme: Simple to Use] Work completed

Enhance Java infrastructure. As part of its increased support for Javadoc, the model will support extracting Javadoc from attached source or HTML. It will allow defining optional classpath entries. The codeassist engine will be support pluggable extensions which can participate and contribute new proposals and/or filter others. Codeassist will support CamelCase pattern; and provide completions on new artifacts such as Javadoc, break/continue label. [JDT Core, JDT Text] (127898) [Theme: Appealing to the Broader Community] Work completed

Support for execution environments. An execution environment describes the capabilities of a Java runtime environment. For example, an execution environment may represent J2SE-1.4. The Java launching infrastructure supports an extensible set of execution environments to be contributed to the platform and for delegates to identify installed JREs compatible with an environment. This allows teams to build, run, and debug based on execution environments rather than being bound to specific installed JREs. Additionally, new APIs will allow JREs to be queried for system properties and specific JRE configurations will be able to be contributed to the set of installed JREs via an extension point. [JDT Core, JDT Debug] (127899) [Theme: Simple to Use] Work completed

Proposed Items (Eclipse JDT project)

None at this time.

Deferred Items (Eclipse JDT project)

Implement library projects. For plug-in development, PDE distinguishes between the plug-in projects you are working on (source plug-in projects) and plug-in projects you are working with but not actually changing (binary plug-in projects). Making this distinction affords the user the benefits of having full source for everything in their workspace where it's easily browsed and searched, while permitting economies because the latter kind of projects do not actually have to be (re)compiled. This work item is to support a similar notion of library project for Java development in general. The user should be able to flag a Java project as a library project; JDT would then know how to present library projects appropriately at the UI, and how to deal with them more efficiently using generated binaries. [JDT Core, JDT UI, PDE] (80162) [Theme: Design for Extensibility]

(End of items for Eclipse JDT project.)

Plug-in development environment (PDE) project

The plug-in development environment (PDE) consists of tools for developing plug-ins for the Eclipse Platform. The following work items reflect new features of PDE, or areas where existing features will be significantly reworked.

Committed Items (Eclipse PDE project)

New source lookup for debugging Eclipse applications. The default source lookup mechanism for debugging Java applications has scalability issues since the debugger may needing to scan a list of hundreds of plug-in projects each time it look up a source file. PDE should provide its own source path computer to which the debugger can delegate the task of locating source files. In addition to faster lookups, the PDE-based approach will be better positioned to handle duplicate source files on the same source path. It would also allow the user to easily debug plug-ins against different targets without having to change the Target Platform in the preferences. [PDE, Debug, Runtime] (106212) [Theme: Scaling Up] Work completed

Improve target support. PDE manages a model of the target Eclipse for which you are developing. Targets may be complex and diverse, and switching targets or launch configurations can be expensive. PDE should be extended to support named targets and automatically track changes to the workspace. [PDE, Runtime] (106211) [Theme: Simple to Use, Enterprise Ready] Work completed

Improve PDE build. PDE Build is fundamental to how the Eclipse Platform releases are produced. It is also increasingly being used by other Eclipse projects and in the wider community. Potential improvements to PDE build include parallel cross-building, incremental building of plug-ins, increased integration with the workspace model, and support for additional repository providers. [PDE] (106214) 106214[Theme: Enterprise Ready] Work completed

Proposed Items (Eclipse PDE project)

None at this time.

Deferred Items (Eclipse PDE project)

API-aware tools. Given the importance that the Eclipse community places on stable, robust APIs, having good support for their implementation is critical. The support within Eclipse for describing APIs should be improved, along with better tools from assisting developers to stick to APIs provided by other plug-ins. [PDE, JDT] (106213) [Theme: Enterprise Ready]

(End of items for Eclipse PDE project.)

Equinox project

The Equinox project provides an implementation of the OSGi R4 core framework specification, a set of bundles that implement various optional OSGi services and other infrastructure for running OSGi-based systems. The following work items reflect new features of Equinox, or areas where existing features will be significantly reworked.

Committed Items (Equinox project)

Give OSGi a first class presence on eclipse.org. Eclipse is based on an efficient, highly scalable OSGi implementation, which has always been usable as a standalone component. OSGi should have a first class presence on eclipse.org, including making it easy for developers to reuse the Eclipse OSGi implementation in their own applications. To support this, a separate OSGi download should be provided, as is done for SWT. [Runtime] (106188) [Theme: Appealing to the Broader Community, Rich Client Platform] Work completed

Refactor the runtime. The Eclipse runtime is currently one monolithic plugin that contains the extension registry, jobs, preferences, content types, application model and various helper/utility classes. Various use cases demand independent use of these facilities. The runtime should be refactored into individual bundles for the different functional areas to improve the support for specific use cases such as using the extension registry on standard OSGi systems or standalone, and better integration between the Eclipse application model and OSGi (e.g., the OSGi MEG application model). [Framework, Bundles, Runtime] (113663) [Theme: Appealing to the Broader Community, Rich Client Platform] Work completed

Proposed Items (Equinox project)

None at this time.

Deferred Items (Equinox project)

None at this time.

(End of items for Equinox project.)

Appendix 1: Execution Environment by Plug-in

In the table below, the "3.2 EE" ("3.2 Execution Environment") column indicates the minimum Java class library requirements of each plug-in for the 3.2 release, where the value is one of:

Entry Meaning
M1.0 OSGi Minimum Execution Environment 1.0 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details.
M1.1 OSGi Minimum Execution Environment 1.1 - This is a subset of the J2ME Foundation class libraries defined by OSGi to be the base for framework implementations. See the OSGi specification for more details.
F1.0 J2ME Foundation 1.0 - indicates that the plug-in can only be run on Foundation 1.0 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.0 is a subset of J2SE 1.3. (see note below)
F1.1 J2ME Foundation 1.1 - indicates that the plug-in can only be run on Foundation 1.1 or greater. Note that with the exception of some MicroEdition IO classes, Foundation 1.1 is a subset of J2SE 1.4. (see note below)
1.2 J2SE 1.2 - indicates that the plug-in can only be run on JSE 1.2 or greater.
1.3 J2SE 1.3 - indicates that the plug-in can only be run on JSE 1.3 or greater.
1.4 J2SE 1.4 - indicates that the plug-in can only be run on JSE 1.4 or greater.
1.4/1.5 Indicates that the plug-in can run on JSE 1.4 or greater, but provides enhanced functionality when run on J2SE 5.0.
1.5 J2SE 5.0 - indicates that the plug-in can only be run on JSE 5.0 or greater.
n/a Not applicable (e.g. documentation and source plug-ins), or not available at the time of this revision.

Note: Plug-ins that are Foundation 1.0 should in fact list Foundation 1.0 AND J2SE1.3 in their execution environments. This is because Foundation 1.0 is not a proper subset of 1.3. Listing them both will in essence say that the intersection of the two is valid for use in that plug-in. The situation is the same for Foundation 1.1 and J2SE1.4.

Table of minimum execution environments by plug-in.

Plug-in
3.2 EE
com.ibm.icu
F1.0
com.ibm.icu.source
n/a
org.apache.ant
1.2
org.apache.lucene
1.3
org.eclipse.ant.core
1.4
org.eclipse.ant.ui
1.4
org.eclipse.compare
1.4
org.eclipse.core.boot
1.4
org.eclipse.core.commands
F1.0
org.eclipse.core.contenttype
F1.0
org.eclipse.core.expressions
F1.0
org.eclipse.core.filebuffers
1.4
org.eclipse.core.filesystem
1.4
org.eclipse.core.jobs
F1.0
org.eclipse.core.resources
1.4
org.eclipse.core.resources.compatibility
1.4
org.eclipse.core.runtime
F1.0
org.eclipse.core.runtime.compatibility
F1.0
org.eclipse.core.runtime.compatibility.auth
F1.0
org.eclipse.core.runtime.compatibility.registry
F1.0
org.eclipse.core.variables
1.4
org.eclipse.debug.core
1.4
org.eclipse.debug.ui
1.4
org.eclipse.equinox.common
F1.0
org.eclipse.equinox.preferences
F1.0
org.eclipse.equinox.registry
F1.0
org.eclipse.help
F1.0
org.eclipse.help.appserver
F1.0
org.eclipse.help.base
1.4
org.eclipse.help.ui
1.4
org.eclipse.help.webapp
1.4
org.eclipse.jdt
1.4
org.eclipse.jdt.apt.core
1.5
org.eclipse.jdt.apt.ui
1.5
org.eclipse.jdt.core
1.4
org.eclipse.jdt.core.manipulation
1.4
org.eclipse.jdt.debug
1.4
org.eclipse.jdt.debug.ui
1.4
org.eclipse.jdt.doc.isv
n/a
org.eclipse.jdt.doc.user
n/a
org.eclipse.jdt.junit
1.4
org.eclipse.jdt.junit.runtime
1.3
org.eclipse.jdt.junit4.runtime
1.5
org.eclipse.jdt.launching
1.4
org.eclipse.jdt.source
n/a
org.eclipse.jdt.ui
1.4
org.eclipse.jface
F1.0
org.eclipse.jface.databinding
1.4
org.eclipse.jface.text
1.4
org.eclipse.ltk.core.refactoring
1.4
org.eclipse.ltk.ui.refactoring
1.4
org.eclipse.osgi (system.bundle)
M1.0
org.eclipse.osgi.services
M1.0
org.eclipse.osgi.util
M1.0
org.eclipse.pde
1.4
org.eclipse.pde.build
1.4
org.eclipse.pde.core
1.4
org.eclipse.pde.doc.user
n/a
org.eclipse.pde.junit.runtime
1.4
org.eclipse.pde.runtime
1.4
org.eclipse.pde.source
n/a
org.eclipse.pde.ui
1.4
org.eclipse.platform
F1.0
org.eclipse.platform.doc.isv
n/a
org.eclipse.platform.doc.user
n/a
org.eclipse.platform.source
n/a
org.eclipse.platform.source.*
n/a
org.eclipse.rcp
F1.0
org.eclipse.rcp.source
n/a
org.eclipse.rcp.source.*
n/a
org.eclipse.sdk
n/a
org.eclipse.search
1.4
org.eclipse.swt
F1.0
org.eclipse.swt.*
F1.0
org.eclipse.team.core
1.4
org.eclipse.team.cvs.core
1.4
org.eclipse.team.cvs.ssh
1.4
org.eclipse.team.cvs.ssh2
1.4
org.eclipse.team.cvs.ui
1.4
org.eclipse.team.ui
1.4
org.eclipse.text
1.4
org.eclipse.tomcat
1.4
org.eclipse.ui
F1.0
org.eclipse.ui.browser
1.4
org.eclipse.ui.cheatsheets
F1.0
org.eclipse.ui.console
1.4
org.eclipse.ui.editors
1.4
org.eclipse.ui.externaltools
1.4
org.eclipse.ui.forms
F1.0
org.eclipse.ui.ide
1.4
org.eclipse.ui.intro
F1.0
org.eclipse.ui.intro.universal
F1.0
org.eclipse.ui.navigator
1.4
org.eclipse.ui.navigator.resources
1.4
org.eclipse.ui.presentations.r21
1.4
org.eclipse.ui.views
1.4
org.eclipse.ui.views.properties.tabbed
F1.0
org.eclipse.ui.win32
1.4
org.eclipse.ui.workbench
F1.0
org.eclipse.ui.workbench.compatibility
1.4
org.eclipse.ui.workbench.texteditor
1.4
org.eclipse.update.configurator
F1.0
org.eclipse.update.core
F1.0
org.eclipse.update.core.linux
F1.0
org.eclipse.update.core.win32
F1.0
org.eclipse.update.scheduler
F1.0
org.eclipse.update.ui
F1.0
org.junit
1.3
org.junit4
1.5
startup.jar
F1.0