The release deliverables have the same form as previous releases, namely:
- Source code release for all Eclipse Project deliverables, available as versions tagged "R3_6" 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 binary and SDK for the Rich Client Platform) (downloadable).
- Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).
- Eclipse PDE (runtime binary and SDK 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.6 with 3.5
Eclipse 3.6 will be compatible with Eclipse 3.5 (and all earlier 3.x versions).
API Contract Compatibility: Eclipse SDK 3.6 will be upwards contract-compatible with Eclipse SDK 3.5 except in those areas noted in the Eclipse 3.6 Plug-in Migration Guide. Programs that use affected APIs and extension points will need to be ported to Eclipse SDK 3.6 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 3.6 APIs would ensure compliance with Eclipse SDK 3.5 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.6 will be upwards binary-compatible with Eclipse SDK 3.5 except in those areas noted in the Eclipse 3.6 Plug-in Migration Guide. Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.6 will not be usable in Eclipse SDK 3.5. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: Eclipse SDK 3.6 will be upwards source-compatible with Eclipse SDK 3.5 except in the areas noted in the Eclipse 3.6 Plug-in Migration Guide. This means that source files written to use Eclipse SDK 3.5 APIs might successfully compile and run against Eclipse SDK 3.6 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.6 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.5 .. 3.0 can be successfully opened by Eclipse SDK 3.6 and upgraded to a 3.6 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.6 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 3.6 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.6 will be unusable with a product based on an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 3.6 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.
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 and DBCS locales are supported by the Eclipse SDK on all reference platforms; BIDI locales are supported by the Eclipse SDK everywhere but on Motif.
The Eclipse SDK supports GB 18030 (level 1), the Chinese code page standard, on Windows XP and 2000, Linux/GTK 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.6 release of the Eclipse Project is developed on a mix of Java 1.4, Java 5 and Java 6 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs. Most functionality is available for 1.4 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.6 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-bitSun Java 5 Update 22
IBM Java 5 SR11 Win32x86 64-bitVistax86 32-bitSun Java 5 Update 22
IBM Java 5 SR11
Oracle JRockit 27.6.5 x86 64-bitSun Java 5 Update 22
IBM Java 5 SR11 XPx86 32-bitSun Java 6 Update 17
Sun Java 5 Update 22
IBM Java 5 SR11
Oracle JRockit 27.6.5 x86 64-bitSun Java 5 Update 22
IBM Java 5 SR11 Red Hat Enterprise Linux5.0x86 32-bitSun Java 6 Update 17
Sun Java 5 Update 22
IBM Java 5 SR11
Oracle JRockit 27.6.5 GTKPower 64-bitIBM Java 5 SR114.0x86 64-bitSun Java 5 Update 22
IBM Java 5 SR11 SUSE Linux Enterprise Server11x86 32-bitSun Java 5 Update 22
IBM Java 5 SR11 GTKx86 64-bitPower 64-bitIBM Java 5 SR11Ubuntu Long Term Support10.04x86 32-bitSun Java 5 Update 22
IBM Java 5 SR11 GTKx86 64-bitSun Solaris10x86 32-bitSun Java 5 Update 22GTKSPARC 32-bitHP-UX11i v2ia64 32-bitHP-UX Java 5 Update 18Motif 2.1IBM AIX5.3Power 32-bitIBM Java 5 SR11Motif 2.1Apple Mac OS X10.5UniversalApple Java 10.5 Update 2CarbonUniversal 32-bitCocoaUniversal 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.
Consumability
This work will make it easier for users to get Eclipse, install it on their systems, and configure it for their use. It also covers work related to error handling and reporting mechanisms, and a number of enhancements to the Debug and PDE tools.