OSGI JAVA模块化框架的另类进化.docVIP

OSGI JAVA模块化框架的另类进化 OSGiJava模块化框架的另类进化阅读次数:312次发布时间:2010-03-2509:09:27发布人:网络转载 来源:网络转载 【IT168评论】我们曾不只一次的听到2010年将是Java模块化的一年的言论;也知道目前为Java提供模块化的OSGi正在受到IBM和Eclipse基金会的大力支持。但作为实现Java模块化应用的基础框架，OSGi似乎并不完美;我们经常能听到关于OSGi过于复杂的抱怨。 从个人的角度，我以开放的心态去了解OSGi。令人失望的是，我发现它的规则非常复杂而且是低阶的(low-level)，对于大多数企业Java环境，需要对其进行许多改善/缩写的工作，才能让它更容易被人理解。对于大多数实际的企业需求，它又显得功能过于强大。比较而言，Jigsaw感觉更“干净”，以Java为中心，紧凑而且易于理解。 说实话，这种抱怨让我有点困惑。我来假设一下，如果OSGi现在并不存在，有人给我一项任务，为Java平台设计一个新的模块系统，那么对于这个模块系统的最合理的需求集合将直接指向OSGi，因为OSGi的设计目的可能是满足我们需求的最简单的解决方案。 是不是我的想象力不够?或者这不过是爱因斯坦剃刀原理(事物应尽可能简单而不是更简单)打败奥卡姆剃刀原理(如无必要，勿增实体)的又一个实例? 另外，我认可OSGi 初看并不是那么简单这一说法，尤其是你不了解它为什么会是现在这样的时候。 在这篇文章中，我将按照上述的那个假设，从零开始设计OSGi系统。当然许多细节问题在这里我不能一一讲述。下面切入正题，为什么OSGi成为现在这个样子?我们一起看看OSGi不算漫长但足够复杂的进化(这种进化是积极的，因为它为解决业界实际存在的问题而生)。 模块分离 我们的第一个需求是清晰地划分模块，这样一个模块中的类就不会具有我们无法控制的功能：使用或覆盖另一个模块中的类。在传统的Java中有一个“classpath”(类路径)，这是一个巨大的类列表，当多个类碰巧使用相同的名称时，总是使用第一个类，而第二个和其他所有的同名类将被忽略。看起来这种事情不会经常发生，当事实并非如此。当存在许多库而这些库又依靠其他库时，这个问题就变得常见了。这个覆盖问题绝??是致命的，因为它会导致一些奇怪的错误，比如LinkageError、 IncompatibleClassChangeError等。事实上能够看到这些错误，那还是比较幸运的。倒霉的是这些错误没有提示，而系统一声不响地错误地运行，哪怕在部署之前我们做了许多先行测试。 对于类的覆盖和不可能空的可见性，预防方法是为每一个模块创建一个类加载器(classloader)。类加载器能够做到仅加载它能够直接识别的类，在我们的这个系统中，就是某个模块的内容(不过，它也可以根据类对类的方式，请求其他类加载器提供类，这种方式称为委派，即delegation)。使用类加载器之后，每个模块包括他需要处理的代码和类，而且能够保证获得按照计划应该使用的类，即使系统中的其他模块包含同名的类。 从整体上恢复可见性等功能 完成以上步骤之后，我们到达这样一个点：所有模块完全隔离，无法互相通信。为了让这个系统变得实用些，我们需要恢复一些功能，以便能够看到其他模块中的类，不过这样做时必须非常谨慎，而且必须使用严格控制的方式。这里我们又多了一个需求：模块需要能够隐藏某些部署细节。 在Java中，protected/默认和public类型之间缺少访问修饰符。假设我写了一个库，希望这个库中其他包能够使用我的一个类，我必须让这个类设置为public。但这样这个类将对所有人是可见的，包括这个库外部的客户，这些客户将能够直接使用我的内部类。我们想要的是一个“模块”级的访问级别，但现在的问题是javac编译器无法区分模块边界在哪里，因此对于这样的访问修饰符它无法执行任何检测。事实上，现有的“默认”访问修饰符也是有问题的，因为它应该只对同一个“运行时包(runtimepackage，即由某个特定类加载器加载的包)”提供访问权。但同样javac无法确定运行时存在哪些加载器。对于这种情况，javac会采取冒险的方式：即使之后会导致IllegalAccessErrors错误，它也会提供访问权。 在我们这个模块系统中，我们选择的解决方式是允许模块仅“导出”其内容的一部分。如果模块中某些部分是非导出的，那么对于其他模块就是不可见的。但默认导出哪些内容?除了某些明显需要隐藏的部分，我们应该导出所有内容吗?或者除了那些明显需导出的部分，我们应该隐藏所有其他内容?选择后者看起来能够到来更好的透明