Thu 07 Jan 2016

Java Classloaders and OSGI


  1. load things from \jre\lib\rt.jar
  2. Run Bootstrap/Primordial/Null classloader
  3. Optionally, Extension classloader gets \jre\lib\ext
  4. System classloader gets things from the classpath

All ClassLoaders except for Bootstrap are themselves Java classes.

We can pass -verbose:class to the Java executable to get some detail about this.

A class is uniquely identified by class loader + class name. The same class may be loaded by different classloaders.

This implies the a classloader my also be loaded multiple times by different classloaders.

Classes loaded by different types or instances of ClassLoader are not compatible.

ClassLoaders should first check if a class exists in their parent before loading it.

This goes inside the jar.

  • Main-Class: classname
  • Class-Path: some.jar some-other.jar
  • Sealed: true to enforce bundling somehow?


Component system "that actually works". It offers some information hiding, and dynamic loading, unloading and reloading of bundles.

Bundles expose some types 'features'.

OSGi adds some stuff to MANIFEST.MF

  • Bundle-SymbolicName is the unique id
  • Bundle-ActivationPolicy can make it init lazily.
  • Export-Package controls what's visible.

extend the BundleActivator class to do start() and stop(). A bundle, while it is in RESOLVED phase, can be started and stopped many times.

Each plugin (bundle?) gets its own classloader.


OSGI has a console, so you can load and unload stuff as you like.

  • ss lists all bundles.

It depends on:

  • org.eclipse.equinox.console
  • org.apache.felix.gogo.command
  • org.apache.felix.gogo.runtime


Equinox implements the OSGi core framework.

Get to the OSGi console using Host OSGi Console.