Our recent research has resulted in a method that ensures safe OSGi bundle updates and package bindings despite potentially errorneous meta-data, e.g. package versions. It uses subtype checks and is implemented as a user-space enhancement of the standard bundle update process. The method was successfully applied in the Knopflerfish and Apache Felix frameworks; these implementations also resulted in some general experiences with the OSGi framework which we want to share.

1. 22nd June 2009, Zurich
Bundle Updates with
Verified Compatibility
Premek Brada
University of West Bohemia
Pilsen, CZ

2. Agenda
• Problems addressed
• Version generator
• Safe bundle update
• How does it work
• Experiences
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 2

3. Problem addressed:
version id  implementation
reality mismatch
• Scenarios When you only import packages and require
some minimal or maximal version it means
– origin that the developer of the library has to do
very good version management. If he changes
– consequences an api and does not change the major number
it can affect an already deployed application.
• Variants With maven you already have the same
problems it compile time but with osgi it can
– false positives/negatives crash at runtime. We need a whole set of new
tools for this problem.
-- comment on Peter Krien’s blog, 6/2009
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 3

4. Scenario 1: Values
Developer assigns Dist VID Correct VID Surface changes
version numbers 0.9.0 1.0.0 n/a
manually  bogus 0.9.2 1.1.0 extension
1.0.0 2.0.0 removal
or incorrect values
(natural human reasons) Dist VID Correct VID Surface changes
1.0.1 1.0.0 n/a
1.0.3 1.0.1 (none)
1.0.4 1.0.2 (none)
Analysis of an
OSGi project 1.2.0 2.0.0 modification
– 1.2.1 2.0.1 (none)
version stream 1.2.2 2.0.2 (none)
of two bundles 1.4.0 2.1.0 extension
1.4.1 2.2.0 extension
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 4

5. Scenario 2: Consequences
Resolver believes
version id 
run-time failures
after clean bind
or update.
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 5

6. Scenario 2: Consequences
Resolver believes
version id 
run-time failures
after clean bind
or update.
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 6

7. Build-time solution:
Version generator
• Provably correct version identifiers
– (developing new bundle version, for update)
– compute changes from previous revision
– assign version numbers according to the
scheme semantics
• Implemented as ant task + supporting libraries
– works on .jar / .class, not on .java source
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 7

8. Run-time solution:
Safe bundle update
• Enhanced update process
– check that declared compatible
is really compatible
– works on bundle .jar files
• Implemented as user-space
bundle
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 8

9. Behind the scenes
• Based on type checking mechanism
• Reconstruct surface of bundle old, new
» actually, this is the hard work
• Check for subtype relation → difference
» the same thing as compiler does on assignment
• Results available for any level of bundle
structure (class, package, exports, bundle)
» use as flags for resolver, turn into version value
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 9

10. Experiences & Summary
• Issues we ran into
– can’t check service interfaces etc
– can’t hook well into resolving process
– can’t rely on version id semantics
• API to access installed bundle’s JARs would help
• With finer and enforced version of “proper
imports” best practice, we can have type-safe
updates and bundle resolving
http://www.kiv.zcu.cz/research/groups/dss/
OSGi DevCon 22.6.2009 Zurich Premek Brada - Bundle Updates with Verified Compatibility 10