Class Loader stunts: OSGi code generation

We'll look at some typical problems with class loading in the order of increased complexity, and develop a small piece of code to solve the most interesting of these problems. Even if you're not going to write a code generation framework right away, this article will give you a more in-depth understanding of low-level operations in the runtime (such as OSGi systems) that statically define dependent modules.

This article also includes a working demo project that contains not only the code shown here, but also two ASM-based code generators for practice.

Class loading site Conversions

Porting a framework to an OSGI system usually requires refactoring the framework in extender mode. This pattern allows the framework to delegate all class load work to the OSGI framework while retaining control over the lifecycle of the application code. The goal of the transformation is to replace the traditional, cumbersome class-loading strategy with class loading using bundle. For example, we want to replace the code like this:

ClassLoader　appLoader　=　Thread.currentThread ().getContextClassLoader();
Class　appClass　=　appLoader.loadClass ("com.acme.devices.SinisterEngine");
...
ClassLoader　appLoader　=　...
Class　appClass　=　appLoader.loadClass ("com.acme.devices.SinisterEngine");

To be replaced by:

Bundle　appBundle　=　...
Class　appClass　=　appBundle.loadClass ("com.acme.devices.SinisterEngine");

Although we have to do a lot of work so that OSGi can load the application code for us, we have at least a graceful and correct way to do our job and work better than ever! Users can now Add/remove applications by installing/uninstalling bundle to the OSGi container. Users can also decompose their applications into multiple bundle, sharing libraries among applications and leveraging other modular capabilities.

Since the context class loader is the standard way for the current framework to load application code, let's say two more words here. Current OSGi does not define a policy to set the context class loader. When a framework relies on the context class loader, the developer needs to know this in advance and set the context class loader manually each time the call goes into that frame. Because it is inconvenient to do so easily, the context class loader is rarely used under OSGi. Some people are currently trying to define how the OSGi container automatically manages the context class loader. But before an official standard emerges, it is best to transfer class loading to a specific application bundle.

Adapter class Loader

Sometimes the code we convert has an externalized class loading policy. This means that the framework's classes and methods receive explicit ClassLoader parameters that allow us to determine where they load the application code. In this case, switching the system to OSGi is simply a matter of getting the bundle object to fit the ClassLoader API. This is an application of the classic adapter pattern.

public　class　BundleClassLoader　extends　ClassLoader　{
　 private　final　Bundle　delegate;

　 public　BundleClassLoader(Bundle　delegate)　{
　　 this.delegate　=　delegate;
　 }

　 @Override
　 public　Class<?>　loadClass(String　name)　throws　 ClassNotFoundException　{
　　 return　delegate.loadClass(name);
　 }
}