Today at OSGi DevCon, the OSGi Alliance announced the availability of the early access for Release 5 of OSGi Core and Enterprise specifications. The final release of OSGi R5 is expected later this Summer.
What's new in OSGi R5?
The OSGi R5 core specification adds a general Resource API which can be used to define a general set of requirements and capabilities. This is a generalisation of the existing Import-Package and Export-Package requirements, which provide a means to write bundles together at resolution time. This information is now introspectable via the Capability and Requirement classes, along with attributes that go along with it. The connections between bundles can also be accessed via the existing BundleWiring class, which is available as an adapter on Bundle via the bundle.adapt(BundleWiring.class).
The generic require/capabilities model is also exposed by the new OSGi Bundle Repository (OBR) format. This provides a generic way of recording a bundle's information and expressing dependencies between bundles in a repository format. This is similar to Eclipse's P2 format, but provides a now standard way to represent this information for generic OSGi runtimes. (Previous versions of OBR have existed for a while, but OSGi R5 is the first specification to standardise the API.) The requirements are also built on namespaces which provide a general way of categorising dependencies, such as osgi.ee to represent different types of Java runtime, osgi.wiring.package and osgi.bundle.bundle namespaces for representing bindings between bundles.
There is a new API for hooking in with Java's ServiceLoader, which does not work well in the presence of multiple classloaders. This API provides a means to mediate loaded bundles, and in some cases, perform bytecode re-writing to ensure that the uses of ServiceLoader are mapped out to calls to an OSGi-aware stub which forwards after setting up the correct thread local classloader. In addition, other hooks have been put in place for bundle wiring, service wiring and framework hooks so that runtime environments (such as Eclipse Virgo) can implement a virtual partitioning scheme between bundles. In the Enterprise specification this is referred to as the Subsystem service.
There are also a number of small improvements to services such as the JMX interface, which can provide more information as exposed from the bundle wiring mechanisms.
Eclipse Equinox already provides some of these specifications, as does Apache Felix. However, since the specification has not yet been officially released these are not yet certified.
