- Equinox source code release, available as versions tagged "R3_5" in the project's
- Framework:
- An OSGi R4.2 Core Framework implementation
- Native launcher and splash screen support
- Compendium Services:
- Application Container - An implementation of the OSGi R4.2 MEG Application Container service.
- Config Admin - An implementation of the OSGi R4.2 Configuration Admin service.
- Device Access Service - An implementation of the OSGi R4.2 Device Access service.
- Declarative Services - An implementation of the OSGi R4.2 Declarative Services specification.
- Event Admin Service - An implementation of the OSGi R4.2 Event Admin Service.
- HTTP Service - An implementation of the OSGi R4.2 HTTP service.
- HTTP Servlet - Generic support for exposing another servlet facility (e.g., an underlying application server) as an OSGi HTTP service.
- IO Connector Service - An implementation of the OSGi R4.2 IO Connector Service.
- Initial Provisioning - An implementation of the OSGi R4.2 Initial Provisioning.
- Log Service - An implementation of the OSGi R4.2 Log service.
- Metatype Service - An implementation of the OSGi R4.2 Metatype service.
- Preferences Service - The Eclipse preference service is an extension of the standard OSGi preference service that adds listeners and the notion of preference scopes.
- User Admin Service - An implementation of the OSGi R4.2 User Admin Service.
- Wire Admin Service - An implementation of the OSGi R4.2 Wire Admin Service.
- p2
- Command line application to mirror repositories.
- Command line application to manage (install / uninstall / update) an eclipse install.
- UI to manage an eclipse installation from within eclipse.
- API to programmatically interact with p2.
- Component model
- Eclipse Extension Registry - The Eclipse extension registry allows bundles to communicate and cooperate using declarative markup and lazy instantiation.
- Equinox Transforms - A framework to provide transformations of bundle resources.
- Security
- Equinox Secure Storage
- Certificate Trust Engine - API for to managing trusted certificates
- Server Side
- HTTP Registry - Support for registering servlets, resources and JSPs via the Eclipse extension registry rather than using the code based OSGi registration mechanisms.
- JSP Registry - Provides a JSP Factory that allows JSP usage with the HTTP Registry.
- Servlet Bridge - Low level hook servlet installed in an existing traditional application server. This servlet launches an embedded Equinox and enables it to handle incoming HTTP requests originally sent to the underlying server.
- HTTP Jetty - A thin layer that exposes an embedded Jetty server as a compliant OSGi HTTP service.
Equinox 3.5 will be backward compatible with Equinox 3.4 (and, hence, with 3.3, 3.2, 3.1 and 3.0).
API Contract Compatibility: Equinox 3.5 will be upwards contract-compatible with Equinox 3.4 except in those areas noted in the Equinox 3.5 Migration Guide. Programs that use affected APIs and extension points will need to be ported to Equinox 3.5 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Equinox 3.5 APIs would ensure compliance with Equinox 3.4 APIs. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain contract compatibility.
Binary (bundle) Compatibility: Equinox 3.5 will be upwards binary-compatible with Equinox 3.4 except in those areas noted in the Equinox 3.5 Migration Guide. Downward bundle compatibility is not supported. Bundles for Equinox 3.5 will not in general be usable in Equinox 3.4. Refer to Evolving Java-based APIs for a discussion of the kinds of API changes that maintain binary compatibility.
Source Compatibility: Equinox 3.5 will be upwards source-compatible with Equinox 3.4 except in the areas noted in the Equinox 3.5 Migration Guide. This means that source files written to use Equinox 3.4 APIs might successfully compile and run against Equinox 3.5 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Equinox APIs, they will not be usable with an earlier version of Equinox.
Non-compliant usage of API's: All non-API methods and classes, and certainly everything in a package with "internal" in its name or those packages marked with "x-internal=true" or with "x-friends" annotations, are considered implementation details which may vary between operating environment and are subject to change without notice. Client bundles that directly depend on anything other than what is specified in the Equinox 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 bundles.
Equinox is designed as the basis for internationalized products. The user interface elements provided by Equinox 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 Equinox on all reference platforms; BIDI locales are supported by Equinox everywhere but on Motif.
Equinox 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 Equinox release targets reasonably current operating environments.
Most of Equinox 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 Equinox 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.).
In general, the 3.5 release of Equinox is developed for a mix of J2ME Foundation 1.0 and 1.1 JREs. Certain bundles do however use facilities in more recent JRE versions. In such cases, the associated capabilities are available when running on the required JRE.
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 Equinox testing on a handful of popular combinations of operating system and Java Platform; these are our reference platforms. Equinox undoubtedly runs fine in many operating environments beyond the reference platforms we test, including those using Java6 VMs. However, since we do not systematically test them we cannot vouch for them. Problems encountered when running Equinox on a non-reference platform that cannot be recreated on any reference platform will be given lower priority than problems with running Equinox on a reference platform.
Equinox 3.5 is tested and validated on the following reference platforms ( multiple updates) (this list is updated over the course of the release cycle):
Reference PlatformsMicrosoft Windows Vista, x86-32, Win32 running (any of):
- Sun Java 2 Standard Edition 5.0 Update 14 for Microsoft Windows
- IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR6b
- BEA JRockit 27.4.0, for Microsoft Windows
Microsoft Windows XP, x86-32, Win32 running (any of):
- Sun Java 2 Standard Edition 6.0 Update 4 for Microsoft Windows
- Sun Java 2 Standard Edition 5.0 Update 14 for Microsoft Windows
- IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR6b
- BEA JRockit 27.4.0, for Microsoft Windows
- Sun Java 2 Standard Edition 1.4.2_16 for Microsoft Windows
- IBM 32-bit SDK for Windows, Java 2 Technology Edition 1.4.2 SR10
Red Hat Enterprise Linux 5.0, x86-32, GTK running (any of):
- Sun Java 2 Standard Edition 6.0 Update 4 for Linux x86
- Sun Java 2 Standard Edition 5.0 Update 14 for Linux x86
- IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR6b
- BEA JRockit 27.4.0, for Linux x86
- Sun Java 2 Standard Edition 1.4.2_16 for Linux x86
- IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 SR10
SUSE Linux Enterprise Server 10, x86-32, GTK running (any of):
- Sun Java 2 Standard Edition 5.0 Update 14 for Linux x86
- IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR6b
SUSE Linux Enterprise Server 10, x86-64, GTK running (any of):
- Sun Java 2 Standard Edition 5.0 Update 14 for Linux x86-64
- IBM 64-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR6b
Microsoft Windows Vista, x86-64, Win32 running (any of):
- Sun Java 2 Standard Edition 5.0 Update 14 for Microsoft Windows (AMD64/EM64T)
- IBM 64-bit SDK for Windows, Java 2 Technology Edition 5.0, SR6b
Microsoft Windows XP Professional x64 Edition, x86-64, Win32 running (any of):
- Sun Java 2 Standard Edition 5.0 Update 14 for Microsoft Windows (AMD64/EM64T)
- IBM 64-bit SDK for Windows, Java 2 Technology Edition 5.0, SR6b
Red Hat Enterprise Linux 4.0 update 2, x86-64, GTK running:
- Sun Java 2 Standard Edition 5.0 Update 14 for Linux x86-64
- IBM 64-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR6b
Sun Solaris 10, SPARC, GTK running:
- Sun Java 2 Standard Edition 5.0 Update 14 for Solaris SPARC
Sun Solaris 10, x86, GTK running:
- Sun Java 2 Standard Edition 5.0 Update 14 for Solaris
HP-UX 11i v2, ia64, Motif 2.1, GTK running:
- HP-UX Java 2 Standard Edition 5.0 Update 7 for Itanium
IBM AIX 5.3, Power, Motif 2.1 running:
- IBM 32-bit SDK, Java 2 Technology Edition 5.0, SR6b
Red Hat Enterprise Linux 5.0, Power, GTK running:
- IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 5.0, SR6b
SUSE Linux Enterprise Server 10, Power, GTK running:
- IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 5.0, SR6b
Apple Mac OS X 10.5, Universal, Carbon running:
- Apple Java for Mac OS X 10.5, Update 1
Apple Mac OS X 10.5, Universal 32-bit, Cocoa running:
- Apple Java for Mac OS X 10.5, Update 1
Apple Mac OS X 10.5, Universal 64-bit, Cocoa running:
- Apple Java for Mac OS X 10.5, Update 1
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.
As Equinox is largely headless, there are very few dependencies on window systems. Where there are UI elements (e.g., in the p2 UI), these elements will work on any configuration supported by SWT.
Scalability and Performance
New usage scenarios for Equinox require it to be faster, smaller, bigger, ... The technology needs to scale up or down to allow Equinox to scale down to small embedded environments as well as scaling up to large server environments. Monitor overall performance and memory consumption which includes the addition of new performance tests for new features.
Robustness
Equinox has become the base for a wide range of platform from embedded to server to desktop and rich client applications. These new scenarios bring new requirements on the execution of Equinox as well as on the programming of its API. The Equinox team will improve the overall robustness by providing APIs for clients where needed and fixing critical bugs. There will also be a focused effort on testability and enhancing the automated test suites.
Consumability
The diversity of Equinox poses a significant problem to end-users and developers alike. Equinox is extremely flexible and configurable. This makes the hard things possible but in some cases the simple things are not as simple as they might be. The Equinox team will make it easier for users to get the relevant pieces of function, install it on their systems, and configure it for their use. Where there is UI, attention will be paid to making it simple and natural to use. We will also make it easier for developers to use our APIs.
Future
Eclipse is evolving quickly. New features in the next OSGi specification R4.2 and e4 will drive numerous changes throughout the Equinox project. Considerable effort will be put into updating Equinox to accomodate and exploit these new scenarios.