Chapter 1. Bundle Class Loader

If you are concerned about which version of a class your application uses, you inevitably have to start dealing with class loaders. In Java, the class loader is the mechanism that controls where class definitions come from and decides whether or not to allow a particular class definition to be used. So, when it comes to versioning and security, class loaders play a central role.

Because version control is also important in OSGi, it follows that class loaders play a key role in the OSGi architecture. One of the main aims of OSGi is to make class loading more flexible and more manageable.

A fundamental rule in OSGi is that every bundle has its own class loader and this class loader is known as the bundle class loader.

You might wonder whether it is really necessary to have a class loader for every bundle. The class loader per bundle architecture is chosen for the following reasons:

In the context of OSGi, where a typical application depends on multiple class loaders (one for each bundle), it is important to understand that the fully-qualified class name—for example, org.foo.Hello—is not sufficient to identify a loaded class uniquely. In general, a loaded class is uniquely identified by combining the classloader identity with the fully-qualified class name.

For example, if the class, org.foo.Hello, gets loaded by the bundle classloader for version 1.3 of bundle A, the loaded class is uniquely identified by the combination of the class loader, A;1.3, and the class name, org.foo.Hello. In this chapter, the following notation is used for the unique identity of the loaded class:

A;1.3/org.foo.Hello

A;1.3/org.foo.Hello

The OSGi specification defines a bundle's class space to be the set of all classes accessible to the bundle's class loader, where each class in the set is a unique instance, qualified by the class loader that loaded it.

A bundle class space includes a bundle's private classes, as well as any public classes imported from the bundle's dependencies.

When you have multiple class loaders at parallel locations in the class loader hierarchy (which is the case with the bundle class loaders), it is actually possible to load multiple, distinct, copies of the same class.

For example, given the appropriate conditions, it is possible that version 1.3 of bundle A and version 2.0 of bundle B could both independently load the class, org.foo.Hello. In this case, you would have two distinct loaded classes, as follows:

A;1.3/org.foo.Hello
B;2.0/org.foo.Hello

A;1.3/org.foo.Hello
B;2.0/org.foo.Hello

The OSGi framework is designed to prevent multiple copies of a class ever appearing in the same class space, because this almost always causes errors at run time. On the other hand, it is permissible for different copies of a class to be loaded into different class spaces. For example, it is perfectly alright for separate applications running in an OSGi container to use different versions of the same class.

One of the key class loader concepts is class loader delegation, which is where a class loader, instead of loading a class itself, asks another class loader to load the class. When class loader delegation occurs, you need to distinguish between:^[1]