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

核心提示：我们将按照复杂性增加的顺序考察一些类加载的典型问题，开发一小段代码来解决这些问题中最有趣的一个，类加载器特技：OSGi代码生成，即使你不打算马上写一个代码生成框架，这篇文章也会让你对静态定义依赖的模块运行时（如OSGi系统）的低级操作有比较深入的了解，目前有些人正在进行尝试，但在一个官方的标准出现之前，这篇文章还包括一

我们将按照复杂性增加的顺序考察一些类加载的典型问题，开发一小段代码来解决这些问题中最有趣的一个。即使你不打算马上写一个代码生成框架，这篇文章也会让你对静态定义依赖的模块运行时（如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。