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

核心提示： 现在我们可以使用前面开发的BundleClassLoader：/*Applicationspace*/Bundleapp=...ClassLoaderappSpace=newBundleClassLoader(app);/**Frameworkspace**Weassumethiscodeise

现在我们可以使用前面开发的BundleClassLoader：

　/*　Application　space　*/　
　Bundle　app　=　...　
　ClassLoader　appSpace　=　new　BundleClassLoader(app);　
　
　/*　
　　*　Framework　space　
　　*　
　　*　We　assume　this　code　is　executed　inside　the　framework　
　　*/　
　ClassLoader　fwSpace　=　this.getClass().getClassLoader();　
　
　/*　Bridge　*/　
　ClassLoader　bridge　=　new　BridgeClassLoader(appSpace,　fwSpace);　

这个加载器首先从应用空间为请求提供服务 - 如果失败，它将尝试框架空间。请注意我们仍然让OSGi为我们做很多重量工作。当我们委托给任何一个类空间时，我们实际上委托给了一个基于OSGi的类加载器 - 本质上，primary和secondary加载器可以根据他们各自bundle的导入/导出（import/export）元数据将加载工作委托给其他 bundle加载器。

此刻我们也许会对自己满意。然而，真相是苦涩的，合并的框架和应用类空间也许并不够！这一切的关键是JVM链接类（也叫解析类）的特殊方式。对于JVM链接类的工作有很多解释：

简短的回答：

JVM以一种细粒度（一次一个符号）的方式来做解析工作的。

冗长的回答：

当JVM链接一个类时，它不需要被连接类的所有引用类的完整的描述。它只需要被链接类真正使用的个别的方法、字段和类型的信息。我们直觉上认为对于JVM来说，其全部是一个类名称，加上一个超类，加上一套实现的接口，加上一套方法签名，加上一套字段签名。所有这些符号是被独立且延迟解析的。例如，要链接一个方法调用，调用者的类空间只需要给类对象提供目标类和方法签名中用到的所有类型。目标类中的其他许多定义是不需要的，调用者的类加载器永远不会收到加载它们（那些不需要的定义）的请求。