OSGi组件框架经历了很多年的演变，从嵌入式系统标准最终扩展成包含Java企业服务器。随着去年OSGi企业规格4，版本4.2（OSGi Enterprise Specification Release 4,Version 4.2）的正式发布，目前已经得到了广泛的使用。同时，OSGi也留下了复杂技术的名声，更对的面向系统程序员，而非主流应用开发者。

　　很多独特的OSGi以Eclipse标准的形式存在。“Eclipse Gemini和Eclipse Virgo（Eclipse双子座和Eclipse处女座）项目已经成熟，而且开始实际的运作，” Mike Milinkovich在上周的EclipseCon 2011上对我们讲道，他Eclipse基金会的执行理事。

　　“Gemini为OSGi企业专家组提供了很多参考实现。Virgo曾经是SpringSource DM服务器，现在开始转移，用于扩展Equinox（OSGi R4针对Spring的核心框架标准，提供可管理性和软件生命周期（能力））。”

　　模块化是OSGi核心内容，允许Java EE组件更轻松地进行插拔操作，因此增加了Java应用的可管理性。

　　OSGi收到了应用服务器厂商的好评，这些厂商雇佣了大量的高级Java程序员。但是下一次OSGi发布版本的改进未必能为主流开发者解决复杂性问题。

　　OSGi模块组合中心对于“Bundle”的概念是将Java类和解释说明相关联。下一个OSGi版本关注绑定聚合的改进。

　　下一个OSGi版本中，之前的复合Bundle模型已经由resolver hook（解析器钩状模型）模型取代，根据BJ Hargrave所述，它是OSGi联盟的CTO,也是Eclipse Equinox项目提交者以及IBM高技术职员。

　　“我们已经大幅削减到这个基础之上，” Hargrave说道。但是resolver hook是一种强大的方法，并不会为典型的开发者简化工作。

　　“这是另一个搬起石头砸自己的脚的机会，” Hargrave警告道，他说大多数开发者“不该编写这些东西。”

　　OSGi模块化的简单替代或者附属物以Java Jigsaw (JSR -294)标准的形式存在。据观察着介绍，Jigsaw标准运作缓慢，事实也确实如此。

　　Jigsaw的成就不包括在不久即将发布的OpenJDK 7中，但是最近在OpenJDK 8提案中被提及。

　　“我一直确信，Java最不愿意做的事情就是另一种模块系统。复合实施很好，但是复合标准对于完全准确的同样的目的就不够好了，” Peter Kriens在电子邮件采访中这样讲道。

　　“模块系统出人意料地难以设计，通过OSGi我们已经证明了成熟的解决方案，” Kriens讲道，他是aQute公司创始人兼OSGi联盟成员。

　　“Jigsaw可能会在同样的墙体内运行，或者它将不能提供模块化，” Kriens说道，他强调这是他的个人观点，不代表OSGi联盟的观点。

　　无论探讨OSGi还是Jigsaw，仍旧是创建新的模块化应用的实例，要求重构原来的代码，这一直是个潜在的圈套。

　　“如果你还没有重构Bundle，可能就做错了，” Jeff McAffer说道，他是EclipseSource的创始人兼CTO。

　　“模块化很好，但是前提是你没有用错误的方法进行，” McAffer 说道。