The OSGi Alliance has made available the Early Draft specifications for the next release of the OSGi platform. As a draft specification, specific features may differ and some may be missing or replaced. The early draft contains specifications for:
- RFC 112 - OBR
- RFC 152 - Subsystems
- RFC 167 - Service Loader support
- RFC 169 - JMX Update
- RFC 172 - Declarative Services Annotations
- RFC 174 - Bundle Collision Hook
- RFC 175 - Versioning update (snapshot)
- RFC 176 - Declarative Services 1.2
OBR: One common problem is how to acquire bundles to install into a running OSGi system. This can currently be achieved with the mvn: protocol consuming from a remote repository, or by using custom protocols such as Eclipse's P2.
Before all of these was the Oscar Bundle Repository, or OBR. (Oscar was the name of the OSGi runtime before it was later renamed to Apache Felix.) This provided an XML file which contained repository information, such as which bundles contained which packages. This allows a resolver to determine which set of bundles needs to be acquired in order to make certain functionality available.
However, whilst OBR has been used (and is available from some repositories) it hasn't been widespread, if only because it has never been formally specified. As a result, some differences can occur based on what version of the OBR specification was used at the time.
The OBR RFC aims to resolve these problems by providing a finalised description of the repository format, such that all OSGi runtimes can finally speak the same language for acquring bundles.
Subsystems: Although OSGi works at the bundle (and service) level, being able to install groups of bundles is often more convenient rather than having to list several individually. Subsystems aims to standardise the concept of features and applications, to allow groups of bundles to be referred to and installed as a single unit, much like WAR files are sets of bundles that can be installed in a single unit.
Different OSGi runtimes (such as Eclipse P2 and Apache Karaf) have different ways of referring to these concepts. As a result, it is not possible to install a P2 feature into Apache Karaf, nor an Apache Karaf feature into P2. Having a standardised representation will allow a compatible feature set which can be used interchangably.
There are some concerns with the current subsystems specification, in that it defines new concepts which are conflated with their download units. As a result, a feature has to remain a separate downloadable element (much like Eclipse features are today) instead of using requirements/capabilities to add the concept of a feature into an existing standalone bundle.
Service Loader support: The Service Loader in Java is surprisingly unmodular, and can cause problems for applications which are using it to acquire services (such as XML parsing). The proposal to enable Service Loader support for legacy applications can provide both a mechanism for registering OSGi services into the Service Loader lookup, and for acquiring services via the Service Loader.
Although Service Loader is less powerful than resolving OSGi services directly, it does provide a means to allow legacy code which is still using the old way to participate in, and be controlled via, the OSGi services mechanism.
Since the ServiceLoader is marked final in Java, one of the way this can work is to use load-time re-writing to redirect calls from the Service Loader to a more ClassLoader aware solution.
JMX Update: this brings the JMX processing, previously covered in Chapter 124 of the Enterprise specifications, in line with the new features available in the 4.3 framework such as bundle wirings, properties, and using generics where applicable.
Declarative Services Annotations: brings standard annotations which can be used in Java code, such as @Component and @Reference. Although annotations like this have been used in Bnd, a standard OSGi supported annotation would permit other tools to be able to use this as well.
Bundle Collisions: this hook can be used to filter out situations where multiple bundles (with the same bundle symbolic name and version) can co-exist. If the framework supports filtering hooks, it is possible to install the same named bundle twice in different contexts. To determine whether this is legal, the bundle collision hook can be used to determine whether this is a valid approach or not.
Versioning Update: One of the major differences between OSGi versioning and Maven versioning is the importance of the unqualified version (e.g. 1.2.3). In Maven, this is the largest possible value, whilst in OSGi this is the lowest possible value. Approaches which use -SNAPSHOT in the Maven world (or .qualifier in Eclipse) are replaced with a dynamic timestamp, but with the expectation that the -SNAPSHOT version will always be lower than the unqualified release. Various schemes have been put into place to work between the two, including even/odd releases (for release/dev), always using a qualified version, or various hard-coded identifiers such as RELEASE to act as a 'top' value.
The version proposal allows two distinct ranges to be provided; the pre-release range and the release range. Pre-release versions are identified with a major.minor.micro- prefix, whilst release ones are major.minor.micro. prefix. It is defined that the pre-release range is less the release range, which happily ensures that 1.2.3-SNAPSHOT is less than 1.2.3. However, it should be noted that 1.2.3 is the 'mid-point' of the range, and that 1.2.3.SNAPSHOT would be higher than 1.2.3.
As with release ranges, the pre-release ranges are sorted lexicographically. Furthermore, since - isn't a valid version at the moment, this change is backward compatible with existing releases. Newer OSGi releases will be able to distinguish between the - ranges.
Declarative Services 1.2: provides a new "greedy" option for consuming services. If a new service is provided, and it has greater priority, then consider being able to replace the implementation that you have with a higher priority one.
Summary: The OSGi specifications are generally well thought out, and these RFCs are no different. Instead of trying to change the world, one rt.jar at a time, the OSGi specs themselves exhibit the same modularity that is encouraged by the platform. By addressing specific issues – such as the ServiceLoader problems caused by classloader unaware code – existing systems can be upgraded to take advantage of that new functionality by running in an OSGi platform.
Possibly the most minor change, but also the most impactful, will be the ability to work with pre-release ranges. This will, at a stroke, allow the Maven and OSGi worlds to come closer together without having to resort to well known tokens to ensure a fixed ordering.
As this is a draft specification, details may change before the public release and this post is intended as an overview of what might be incorporated in future.