从个人的角度，我以开放的心态去了解OSGi。令人失望的是，我发现它的规则非常复杂而且是低阶的(low-level)，对于大多数企业 Java 环境，需要对其进行许多改善/缩写的工作，才能让它更容易被人理解。对于大多数实际的企业需求，它又显得功能过于强大。比较而言，Jigsaw 感觉更“干净”，以 Java 为中心，紧凑而且易于理解。

　　说实话，这种抱怨让我有点困惑。我来假设一下，如果OSGi 现在并不存在，有人给我一项任务，为Java 平台设计一个新的模块系统，那么对于这个模块系统的最合理的需求集合将直接指向OSGi，因为OSGi的设计目的可能是满足我们需求的最简单的解决方案。

　　是不是我的想象力不够 或者这不过是爱因斯坦剃刀原理(事物应尽可能简单而不是更简单)打败奥卡姆剃刀原理(如无必要，勿增实体)的又一个实例

　　另外，我认可OSGi 初看并不是那么简单这一说法，尤其是你不了解它为什么会是现在这样的时候。

OSGi框架的各个组成部分

　　在这篇文章中，我将按照上述的那个假设，从零开始设计OSGi 系统。当然许多细节问题在这里我不能一一讲述。下面切入正题，为什么OSGi 成为现在这个样子 我们一起看看OSGi不算漫长但足够复杂的进化(这种进化是积极的，因为它为解决业界实际存在的问题而生)。

　　模块分离

　　我们的第一个需求是清晰地划分模块，这样一个模块中的类就不会具有我们无法控制的功能：使用或覆盖另一个模块中的类。在传统的 Java 中有一个“classpath”(类路径)，这是一个巨大的类列表，当多个类碰巧使用相同的名称时，总是使用第一个类，而第二个和其他所有的同名类将被忽略。看起来这种事情不会经常发生，当事实并非如此。当存在许多库而这些库又依靠其他库时，这个问题就变得常见了。这个覆盖问题绝对是致命的，因为它会导致一些奇怪的错误，比如 LinkageError、IncompatibleClassChangeError 等。事实上能够看到这些错误，那还是比较幸运的。倒霉的是这些错误没有提示，而系统一声不响地错误地运行，哪怕在部署之前我们做了许多先行测试。

　　对于类的覆盖和不可能空的可见性，预防方法是为每一个模块创建一个类加载器(class loader)。类加载器能够做到仅加载它能够直接识别的类，在我们的这个系统中，就是某个模块的内容(不过，它也可以根据类对类的方式，请求其他类加载器提供类，这种方式称为委派，即 delegation)。使用类加载器之后，每个模块包括他需要处理的代码和类，而且能够保证获得按照计划应该使用的类，即使系统中的其他模块包含同名的类。

　　从整体上恢复可见性等功能

　　完成以上步骤之后，我们到达这样一个点：所有模块完全隔离，无法互相通信。为了让这个系统变得实用些，我们需要恢复一些功能，以便能够看到其他模块中的类，不过这样做时必须非常谨慎，而且必须使用严格控制的方式。这里我们又多了一个需求：模块需要能够隐藏某些部署细节。

　　在 Java 中，protected/默认和 public 类型之间缺少访问修饰符。假设我写了一个库，希望这个库中其他包能够使用我的一个类，我必须让这个类设置为 public。但这样这个类将对所有人是可见的，包括这个库外部的客户，这些客户将能够直接使用我的内部类。我们想要的是一个“模块”级的访问级别，但现在的问题是 javac 编译器无法区分模块边界在哪里，因此对于这样的访问修饰符它无法执行任何检测。事实上，现有的“默认”访问修饰符也是有问题的，因为它应该只对同一个“运行时包(runtime package，即由某个特定类加载器加载的包)”提供访问权。但同样 javac 无法确定运行时存在哪些加载器。对于这种情况，javac 会采取冒险的方式：即使之后会导致 IllegalAccessErrors 错误，它也会提供访问权。

　　在我们这个模块系统中，我们选择的解决方式是允许模块仅“导出”其内容的一部分。如果模块中某些部分是非导出的，那么对于其他模块就是不可见的。但默认导出哪些内容 除了某些明显需要隐藏的部分，我们应该导出所有内容吗 或者除了那些明显需导出的部分，我们应该隐藏所有其他内容 选择后者看起来能够到来更好的透明度：我们可以很方便查看导出列表，确定那些可见的部分，即模块的“表面部分”。

　　请注意，我目前还没指定具体导出什么内容，这是一个需要仔细考虑的问题。