OSGi members are currently voting on these and once that is done the same text will be released as 'final' specification. Let's dive in to see what's new!
Promise<InputStream> masterURL =
prepareDownload().then(p -> getMirror(p.getValue()).
then(p -> p.getValue().openStream());
Promises integrate very well with Java 8 lambdas and support monadic programming. They can be used both inside as well as outside of an OSGi Framework.
- Asynchronous Services - This specification can turn any regular OSGi service into an asynchronous service. It leverages the Promises API as described above and supports turning ordinary services into async ones. It also provides support for developing new services that are specifically implemented to be asynchronous.
- HTTP Whiteboard Service - OSGi has provided a simple mechanism to register servlets for a long time via the HTTP Service specification. This specification, although widely used, has aged a little. The new HTTP Whiteboard specification supports Servlets, Filters, static resources and Http/Servlet listeners based off the Servlet 3.1 specification. It leverages the OSGi Whiteboard pattern (www.osgi.org/wiki/uploads/Links/whiteboard.pdf) to register them, which effectively means that if you register a Servlet or a Filter as a service, it will be made available by the whiteboard runtime. This specification also includes a wide range of DTOs to allow runtime introspection.
- Declarative Services - This specification has undergone extensive changes bringing several exciting enhancements: new annotations for field injection, a strong-typed mechanism based on annotations for providing configuration and DTOs for introspection. Declarative Services now also support Prototype Service Factories which were introduced in the Core R6 release. Numerous other small improvements were also made to DS.
- Remote Service Admin - This specification has had minor updates which allow remote endpoints to be updated. In the past the only way to do this was to remove/re-add the endpoint but in practise this caused unnecessary volatility in the system, especially for discovery providers. With the update facility this volatility is now avoided.
- Repository - The OSGi Repository service now supports composite queries that span multiple namespaces. With this you can ask the repository questions like 'Is there a bundle that exports javax.mail and has the ASL license?' As this information is expressed in different capability namespaces, it's an example of a composite query. A requirement builder utility has also been added to by this specification to make the developer's life easier.
- Subsystems - This specification has been updated to allow providing a Deployment Manifest at deploy time. No longer does it need to be embedded in the subsystem archive. Deployment manifests freeze the dependencies that a subsystem has to particular versions; for example the versions validated during a QA phase. With this release these manifests can be provided separately, without the need to modify the subsystem archive (.esa file). The subsystems specification also received a number of other updates.
Note that if the implementation is an extender, then osgi.extender is used instead of osgi.implementation.
Specifications that have been updated in this round have these standard capabilities added, where this made sense.
In addition, Portable Java Contracts have been defined using the osgi.contract namespace to achieve portable bundles for JSR-based java packages that don't follow semantic versioning. This allows for portable consumer bundles of these packages. See here: http://blog.osgi.org/2014/09/portable-java-contracts-for-javax.html and http://www.osgi.org/Specifications/ReferenceContract.