OSGI is a Java platform that introduces modularity. It allows Java applications to be broken into separate bundles that can be dynamically installed and updated without restarting the JVM. Each bundle contains metadata that defines its dependencies and exported/imported packages. The OSGI framework handles loading and wiring bundles together based on their dependencies. This allows applications to be updated modularly rather than requiring redeploys of the entire application.

1. OSGI Modularity
Pubudu Dissanayake

3. The What and Why of OSGI
What do you mean by “Modularity” ?
the logical decomposition of a large
system into smaller collaborating pieces
Widely accepted specification which introduces a standard way of
building dynamic, modular systems with Java.
What is OSGi?

4. Why OSGI ?
Java’s modularity limitations
● Low-level code visibility control

5. Java’s modularity limitations Cont..
● Error-Prone Classpath concept
The classpath pays no attention to code versions - it returns first version it finds.
Class Path Hell !

7. Typical Java Application

8. ● Runtime vs Compile time difference.
○ Flat, single classpath.
Java’s modularity limitations Cont..
● No standard way of building a modular system.
○ Class loader based techniques.
● If you need to add new functionality or update existing functionality, JVM needed to be restarted.
● Can you update a part(can be a JAR file) of a running Java application?
● Java lacks dynamism

9. Can OSGI help you ?
● Allow us to understand the system easily
● Allow us to develop module by module
● Allow us to reuse developed modules
● ClassNotFoundException when starting your application
● Execution time error due to wrong version of dependent library
● Packaging an application as logically independent JAR files and deploying only those pieces
you need for a given installation.
● Packaging an application as logically independent JAR files, declaring which code is accessible
from each JAR file, and having this visibility enforced.
“Yes !! ” Still not convinced ??

10. Next level of Modularity

11. An Architectural overview of OSGI

12. OSGI Framework
As of now, there are 3 implementations
● Apache Felix
● Eclipse Equinox
● Knopflerfish
Module Layer Lifecycle Layer
Service Layer

13. OSGI Modularity
● Is how OSGI refers to its specific realization of the module concept
● Is a jar file with extra Meta-data. bundles typically aren’t entire application
packaged into single jar file.
● Is more powerful than a jar file because it can explicitly declare visibility of its
packages. Thus it extends normal access modifies association with java
Bundle

14. The Bundle role in physical modularity
● Is to determine module membership
● Given class is a member of a bundle if it’s contained in the bundle jar
● Bundle jar is a container of bundle metadata -- Manifest

15. Bundle role in logical Modularity
● Is to logically encapsulate member classes. what does this mean ?
○ Visibility of the code

16. Defining Bundle with metadata
● Human-readable information—Optional information intended purely as an aid to humans who
are using the bundle
● Bundle identification —Required information to identify a bundle
● Code visibility —Required information for defining which code is internally visible and which
internal code is externally visible
● Human-readable information
Bundle-Name: Simple Paint API
Bundle-Description: Public API for a simple paint program.
Bundle-DocURL: http://www.manning.com/osgi-in-action/
Bundle-Category: example, library
Bundle-Vendor: OSGi in Action
Bundle-ContactAddress: 1234 Main Street, USA
Bundle-Copyright: OSGi in Action

17. Bundle identification
● For example, Bundle-Name seems like it could be a form of bundle identification
It isn’t.
unique bundle identifier was proposed to maintain backward compatibility it’s called
Bundle-SymbolicName: org.foo.shape
● only intended for the OSGi framework to help uniquely identify a bundle.
A bundle is uniquely identified by its Bundle-SymbolicName and Bundle-Version.
Bundle-SymbolicName: org.foo.shape
Bundle-Version: 2.0.0

18. OSGI Version Number format
● major – Changes for an incompatible update for both a consumer and a provider of an API.
● minor – Changes for a backward compatible update for a consumer but not for a provider.
● micro – A change that does not affect the API, for example, a typo in a comment
● Qualifier - e.g. 1.2.0.alpha

19. Code visibility
● Internal bundle class path—The code forming the bundle
● Exported internal code—Explicitly exposed code from the bundle class path for sharing with
other bundles
● Imported external code—External code on which the bundle class path code depends
Recap
If the JAR file has a Main-Class
java -jar app.jar
If not,
java -cp app.jar org.foo.Main

21. Bundle-ClassPath
The Bundle-ClassPath specifies where to load classes from from the bundle.
Bundle-ClassPath: .
Loading from nested JARs (whether packed or unpacked):
Bundle-ClassPath: foo.jar,other.jar,classes

22. Export - Package
Export-Package : A comma-separated list of internal bundle packages to
expose for sharing with other bundles
Export-Package: org.foo.shape
Export-Package: org.foo.shape,org.foo.other
Export-Package: org.foo.shape; org.foo.other; version="2.0.0"

23. Import-Package
Import-Package :
A comma-separated list of packages needed by internal bundle code from other bundles.
Import-Package: org.foo.shape
there’s NO relationship among nested packages.
Import-Package: org.foo.shape,org.foo.shape.other
Import-Package: org.osgi.framework; version="1.3.0"
Version range ??

24. Version Range
Import-Package: org.osgi.framework; version="[1.3.0,2.0.0)"
“Depending on packages, not bundles.”

25. Class-search order
● If the class is from a package starting with java. ,the parent class loader is asked for the class. If
the class is found, it’s used. If there is no such class, the search ends with an exception.
● If the class is from a package imported by the bundle, the framework asks the exporting bundle
for the class. If the class is found, it’s used. If there is no such class, the search ends with an
exception.
● The bundle class path is searched for the class. If it’s found, it’s used. If there is
no such class, the search ends with an exception.
That’s it! We’ve finished the introduction to bundle metadata

26. Example ..

27. Paint Example ….
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.shape.circle
Bundle-Version: 2.0.0
Bundle-Name: Circle Implementation
Import-Package: javax.swing, org.foo.shape;
version="2.0.0"
Export-Package: org.foo.shape.circle; version="
2.0.0"
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.paint
Bundle-Version: 2.0.0
Bundle-Name: Simple Paint Program
Import-Package: javax.swing, org.foo.shape; org.foo.shape.
circle;
org.foo.shape.square; org.foo.shape.triangle; version="2.0.0"

28. Bundle dependency resolution - Resolving dependencies
automatically
Transitive Dependencies

29. Transitive Bundle-resolution Wiring

30. Multiple Matching Package Providers
● Framework favors the highest matching version
● Sound simple enough ? What if both bundles export same version ?
● framework chooses between candidates based on the order in
which they are installed in the framework.

31. Priority of Dependency
● Highest priority is given to already-resolved candidates, where multiple matches of resolved
candidates are sorted according to version and then installation order.
● Next priority is given to unresolved candidates, where multiple matches of unresolved
candidates are sorted according to version and the installation order.

32. Ensuring Consistency
What went wrong ?

33. Inner vs Inner bundle dependencies

35. Reviewing the benefits of the modular program

36. Summary

37. References
● http://moi.vonos.net/java/osgi-classloaders/
● http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
● OSGi in Action: Creating Modular Applications in Java by: Richard Hall,
Karl Pauls, Stuart McCulloch, David Savage (01 May 2011)

38. Thank You :)