【IT168 评论】我们曾不只一次的听到2010年将是Java模块化的一年的言论;也知道目前为Java提供模块化的OSGi正在受到IBM和Eclipse基金会的大力支持。但作为实现Java模块化应用的基础框架，OSGi似乎并不完美;我们经常能听到关于OSGi过于复杂的抱怨。

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

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

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

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

OSGi框架的各个组成部分

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