The OSGi bundle class loading algorithm plays a key role in the OSGi framework. Ultimately, it is this algorithm that defines the relationship between a bundle and its dependencies.
Here are some of the requirements that a bundle class loader must satisfy in order to support a flexible and consistent class loading architecture:
In order to avoid loading multiple copies of a class, the bundle class loader must first of all try to find the class in one of its dependent bundles.
The bundle class loader must never load a duplicate copy of a class into its class space.
The following is a simplified description of the bundle class loading algorithm (for example, it does not enumerate all of the ways in which class loading can fail). For a full description of the algorithm, see the Runtime Class Loading section of the OSGi Core Specification.
If the class belongs to one of the
java.*packages or any packages listed in theorg.osgi.framework.bootdelegationproperty, the bundle class loader delegates to the parent class loader.If the class belongs to one of the packages listed in
Import-Package, the bundle class loader delegates loading to the corresponding exporter bundle.If the class belongs to one of the packages imported by
Require-Bundle, the bundle class loader delegates loading to the corresponding exporter bundle.![[Note]](imagesdb/note.gif)
Note It is strongly recommended that you avoid using the
Require-Bundleheader. OSGi dependencies are meant to be defined at package granularity, not bundle granularity.Next, the bundle class loader looks for the class amongst its internal classes (inside its own JAR file).
Next, the bundle class loader searches the internal classes of any fragments attached to the bundle.
Finally, if the class belongs to one of the packages imported using
DynamicImport-Package, the bundle class loader delegates loading to the corresponding exporter bundle (if there is one).
 |  |  |
 |
