The release deliverables have the same form as previous releases, namely:
- Source code release for all Eclipse Project deliverables, available as versions tagged "R3_7" in the Eclipse Project CVS repository.
- Eclipse SDK (runtime binary and SDK for Equinox[*], Platform, JDT, and PDE) (downloadable).
- Eclipse Platform (runtime binary and SDK for the Equinox[*] and Platform only) (downloadable).
- Eclipse RCP (runtime and source repositories for the Rich Client Platform) (downloadable).
- Eclipse JDT (runtime and source repositories for the Java Development Tools) (downloadable).
- Eclipse PDE (runtime and source repositories for the Plug-in Development Environment) (downloadable).
- Eclipse SDK Examples (downloadable).
- SWT distribution (downloadable).
* The Equinox Project is part of the top level RT Project. A significant portion of the Equinox deliverables are consumed and redistributed as part of the Eclipse Project's SDK, Platform, and RCP deliverables.
Compatibility of Release 3.7 with 3.6
Eclipse 3.7 will be compatible with Eclipse 3.6 (and all earlier 3.x versions).
API Contract Compatibility: Eclipse SDK 3.7 will be upwards contract-compatible with Eclipse SDK 3.6 except in those areas noted in the Eclipse 3.7 Plug-in Migration Guide. Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.7 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.7 APIs would ensure compliance with Eclipse SDK 3.6 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.7 will be upwards binary-compatible with Eclipse SDK 3.6 except in those areas noted in the Eclipse 3.7 Plug-in Migration Guide. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.7 will not be usable in Eclipse SDK 3.6. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: Eclipse SDK 3.7 will be upwards source-compatible with Eclipse SDK 3.6 except in the areas noted in the Eclipse 3.7 Plug-in Migration Guide. This means that source files written to use Eclipse SDK 3.6 APIs might successfully compile and run against Eclipse SDK 3.7 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.7 will be upwards workspace-compatible with earlier 3.x versions of the Eclipse SDK unless noted. This means that workspaces and projects created with Eclipse SDK 3.6 .. 3.0 can be successfully opened by Eclipse SDK 3.7 and upgraded to a 3.7 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.7 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.7 plug-in developers are responsible for ensuring that their plug-ins recognize metadata from earlier versions 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.7 will be unusable with a product based on an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.7 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 or x-internal in the bundle manifest entry, 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.
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, DBCS, and BIDI locales are supported by the Eclipse SDK on all reference platforms.
The Eclipse SDK supports GB 18030 (level 1), the Chinese code page standard, on Windows, Linux and the Macintosh.
German and Japanese locales are tested.
In order to remain current, each Eclipse Project 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 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.1, J2SE 1.4, Java 5, etc).
In general, the 3.7 release of the Eclipse Project is developed on a mix of Java SE 5 and Java SE 6 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs. Most functionality is available for Java SE 5 level development everywhere, and extended development capabilities are made available on the VMs that support them.
Appendix 1 contains a table that indicates the class library level required for each bundle.
There are many different implementations of the Java Platform running atop a variety of operating systems. We focus our 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.
Eclipse 3.7 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):
table.platforms { border-width: 1px; border-spacing: 0px; border-style: solid; border-collapse: separate; } table.platforms th { border-width: 1px; padding: 3px; border-style: inset; border-color: black; background-color: #B9A9FF; } table.platforms td { border-width: 1px 1px 1px 1px; padding: 3px 3px 3px 3px; border-style: inset inset inset inset; border-color: gray gray gray gray; } table.platforms tr.c0 td { background-color: #FDFDFD; } table.platforms tr.c1 td { background-color: #F4EEFF; } Operating SystemVersionHardwareJREWindowing SystemWindows7x86 32-bitOracle Java 6 Update 17
IBM Java 6 SR8 Win32x86 64-bitVistax86 32-bitx86 64-bitXPx86 32-bitx86 64-bitRed Hat Enterprise Linux 6x86 32-bitOracle Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bitPower 64-bitIBM Java 6 SR8SUSE Linux Enterprise Server11x86 32-bitOracle Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bitPower 64-bitIBM Java 6 SR8Ubuntu Long Term Support10.04x86 32-bitOracle Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bitOracle Solaris10x86 32-bitOracle Java 6 Update 17GTKSPARC 32-bitHP-UX11i v2ia64 32-bit HP-UX Java 6 Update 10GTKIBM AIX5.3Power 64-bitIBM Java 6 SR8GTKApple Mac OS X10.6Universal 32-bitApple Java 10.6 Update 2CocoaUniversal 64-bit
As stated above, we expect that Eclipse works fine on other current Java VM and OS versions but we cannot flag these as reference platforms without significant community support for testing them.
Platforms
This work is focused on ensuring that Eclipse takes full advantage of all capabilities of the underlying technologies that it is based on, be they operating system, window system, Java or other. This includes support for native accessibility, internationalization and localization capabilities.
Robustness
As the basis for the entire Eclipse eco-system, the Eclipse SDK must be robust, flexible and secure. This work will address those issues by providing API for missing or currently internal functionality, and focusing on the issues that affect the stability of the platform.
Ease of Use
The Eclipse platform is not lacking in functionality, but sometimes fails to present that functionality to end users in a way that is easy to discover and use. This theme encompasses work to simplify and improve the end user experience, and to keep up with modern user interface input forms such as multi-touch gestures.