【IT168 评论】我们曾不只一次的听到2010年将是Java模块化的一年的言论;也晓得目前为Java提供模块化的OSGi正在遭到IBM和Eclipse基金会的大力支持。但作为实现Java模块化使用的基础框架，OSGi似乎并不完美;我们经常能听到关于OSGi过于复杂的抱怨。
从个人的角度，我以开放的心态去理解OSGi。令人失望的是，我发现它的规则非常复杂而且是低阶的(low-level)，对于大少数企业 Java 环境，需要对其进行许多改善/缩写的工作，才干让它更容易被人理解。对于大少数实际的企业需求，它又显得功能过于强大。比较而言，Jigsaw 感觉更“洁净”，以 Java 为中心，紧凑而且易于理解。
说实话，这种抱怨让我有点困惑。
jeanjack我来假设一下，如果OSGi 如今并不存在，有人给我一项义务，为Java 平台设计一个新的模块系统，那么对于这个模块系统的最合理的需求集合将直接指向OSGi，因为OSGi的设计目的可能是满足我们需求的最复杂的解决方案。
是不是我的想象力不够?或者这不过是爱因斯坦剃刀原理(事物应尽可能复杂而不是更复杂)打败奥卡姆剃刀原理(如无必要，勿增实体)的又一个实例?
另外，我认可OSGi 初看并不是那么复杂这一说法，尤其是你不理解它为什么会是如今这样的时候。
在这篇文章中，我将依照上述的那个假设，从零末尾设计OSGi 系统。当然许多细节问题在这里我不能一一讲述。下面切入正题，为什么OSGi 成为如今这个样子?我们一起看看OSGi不算漫长但足够复杂的进化(这种进化是积极的，因为它为解决业界实际存在的问题而生)。
