Introduction to OSGi by Peter Kriens

Peter first reminded us the history of computing : we started working with bits (10011100), then octal, hexadecimal, assembler, functions, classes, packages; we kept on encapsulating the code.

Then came the jars; but they did not define a namespace; and as such, they’re not modules and there is no encapsulation.

This problem got solved using bundles (in OSGi); defining extra information on the jars : some packages are private(if you don’t know something, you can not do anything wrong with it ); some others are exported

To add with modularity, OSGi introduced the opportunity to expose API (though interfaces) and not expose your implementations; because you don’t want to share it.

Also services were introduced : a provider provides a service; and each consumer can register it. (Peter showed a slide with an annotated component : @Activate @Component, etc.. to show how trivial it can be to consume a service)

Some services are being part of the specifications (JPA, JNDI, etc..)

OSGi 4.3 Technical update : what’s new ?, by BJ Hargrave

The draft will be available end of week, release in a few months

In this release :

• generics : are not available yet since, the embedded world is still not using it widely; there is a compilator option, -target jsr14, that allows to compile java 5 code for 1.4 JRE.
• The framework and Service Tracker got generified, for example ServiceTracker<S,T> (with S for the service  and T for the type implementing it); we now type safe use of services.
• A new manifest header : Provide-Capability , to provide info such as : « resolve this bundle only if it provides this capability »; and the symmetry is complete with the Require-Capability ; for example, a bundle may provide the SWT API for linux; and another bundle may define : « I want to only resolve if a bundle provides SWT API for linux »
• Bundle-RequiredExecutionEnvironment got deprecated; instead we could use : Provide-Capability: osgi.ee= »JavaSE »; version:List<Version>= »1.5,1.6″ and the other bundle defining : Require-Capability: osgi.ee; filter:=(&(osgi.ee=JavaSe)(version>=1.6))
• Bundle.adapt , to « cast »a bundle; BundleStartLevel bsl =  bundle.adapt(BundleStartLevel.class) to have the current StartLevel of the bundle (the same for BundleWiring too) the introduction of BundleRevision relying on adapt, makes you able to know (through API) which revisions of a bundle is deployed in the system (for example if you have a bundle present in the system in different versions)
• Bytecode weaving : you can now give a bundle some new import directives, live, while it is deployed and started into the system
• ResolverHook : to narrow down the list of bundles considered when importing packages (the hook will get the list of all bundles available, and then provide a short list of bundles exporting this package)
• in 4.2, you could have only one bundle alive in the system with the same symbolic name and version (implicit singleton); the property « multiple » has been introduced, so that in the framework, you can use twice the same bundle in different wiring schemes.

Compendium 4.3 will be out fall 2011, with new compendium services, enterprise 4.3 in 2012 introducing subsystems and OBR (OSGi Bundle Repository)