The release deliverables have the same form as the 4.0 release, namely:
- Source code release for all Eclipse Project deliverables, available as versions tagged "R4_1" in the Eclipse Project CVS repository.
- Eclipse SDK (runtime binary and SDK for Equinox[*], Platform, JDT, and PDE) (downloadable).
- A p2 repository containing the Eclipse 4.1 SDK for all supported platforms.
* 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 4.1 with 4.0
Eclipse 4.1 will be compatible with Eclipse 4.0 (and all earlier 3.x versions).
API Contract Compatibility: All new API in Eclipse SDK 4.0 was provisional. Therefore there is no contract compatibility between releases 4.0 and 4.1. However, this release includes all mature API from the 3.7 release, which is fully contract-compatible with the API in the 3.6 release, except in those areas noted in the Eclipse 3.7 Plug-in Migration Guide. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 4.1 APIs would ensure compliance with Eclipse SDK 4.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: All new API in Eclipse SDK 4.0 was provisional. Therefore there is no binary compatibility between releases 4.0 and 4.1. However, this release includes all mature API from the 3.7 release, which is fully binary-compatible with the API in the 3.6 release, except in those areas noted in the Eclipse 3.7 Plug-in Migration Guide. Downward binary compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 4.1 APIs would ensure compliance with Eclipse SDK 4.0 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: All new API in Eclipse SDK 4.0 was provisional. Therefore there is no source compatibility between releases 4.0 and 4.1. However, this release includes all mature API from the 3.7 release, which is fully source-compatible with the API in the 3.6 release, except in those areas noted in the Eclipse 3.7 Plug-in Migration Guide. This means that source files written to use Eclipse SDK 4.0 APIs are unlikely to compile and run against Eclipse SDK 4.1 APIs, and vice-versa.
Workspace Compatibility: Eclipse SDK 4.1 will be upwards workspace-compatible with earlier versions of the Eclipse SDK unless noted. This means that workspaces and projects created with Eclipse SDK 4.0, 3.6 .. 3.0 can be successfully opened by Eclipse SDK 4.1 and upgraded to a 4.1 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 4.1 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 4.1 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 4.1 will be unusable with a product based on an earlier version of Eclipse. Visible metadata files created (or overwritten) by Eclipse 4.1 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 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 4.1 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 4.1 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 6 Update 17
IBM Java 6 SR8 Win32x86 64-bitVistax86 32-bitx86 64-bitXPx86 32-bitx86 64-bitRed Hat Enterprise Linux5.0x86 32-bitSun Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bit4.0x86 64-bitSUSE Linux Enterprise Server11x86 32-bitSun Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bitUbuntu Long Term Support10.04x86 32-bitSun Java 6 Update 17
IBM Java 6 SR8 GTKx86 64-bitApple 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.
Enterprise Ready
This work is focused on taking the rough technology of the 4.0 release and making it ready for use in interprise applications. This includes providing API, documentation, accessibility, internationalization and localization capabilities.