类加载器特技：OSGi代码生成

类加载器特技：OSGi代码生成2011-06-11 infoq 译:曹云飞我们将按照复杂性增加的顺序考察一些类加载的典型问题，开发一小段代码来解决这些问题中最有趣的一个。即使你不打算马上写一个代码生成框架，这篇文章也会让你对静态定义依赖的模块运行时（如OSGi系统）的低级操作有比较深入的了解。

这篇文章还包括一个可以工作的演示项目，该项目不仅包含这里演示的代码，还有两个基于ASM的代码生成器可供实践。

类加载地点转换

把一个框架移植到OSGi系统通常需要把框架按照extender模式重构。这个模式允许框架把所有的类加载工作委托给OSGi框架，与此同时保留对应用代码的生命周期的控制。转换的目标是使用应用bundle的类加载来代替传统的繁复的类加载策略。例如我们希望这样替换代码：

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

替换为：

Bundle appBundle = ...
Class appClass = appBundle.loadClass （"com.acme.devices.SinisterEngine"）;

尽管我们必须做大量的工作以便OSGi为我们加载应用代码，我们至少有一种优美而正确的方式来完成我们的工作，而且会比以前工作得更好！现在用户可以通过向OSGi容器安装/卸载bundle而增加/删除应用。用户还可以把他们的应用分解为多个bundle，在应用之间共享库并利用模块化的其他能力。

由于上下文类加载器是目前框架加载应用代码的标准方式，我们在此对其多说两句。当前OSGi没有定义设置上下文类加载器的策略。当一个框架依赖于上下文类加载器时，开发者需要预先知道这点，在每次调用进入那个框架时手工设置上下文类加载器。由于这样做易于出错而其不方便，所以在OSGi下几乎不使用上下文类加载器。在定义OSGi容器如何自动管理上下文类加载器方面，目前有些人正在进行尝试。但在一个官方的标准出现之前，最好把类加载转移到一个具体的应用bundle。

适配器类加载器

有时候我们转换的代码有外部化的类加载策略。这意味着框架的类和方法接收明确的ClassLoader 参数，允许我们来决定他们从哪里加载应用代码。在这种情况下，把系统转换到OSGi就仅仅是让Bundle对象适配ClassLoader API的问题。这是一个经典的适配器模式的应用。

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）;
  }
}