当每个人都对OSGi进行标准化时，为什么Sun会发明另一个模块系统？
Sun正在以Jigsaw的forms将JDK模块化，并且暗示它应该是其他Java开发人员的首选模块格式。 使用它的唯一值得注意的玩家是NetBeans（和衍生应用程序）。
另一方面，业界已经围绕OSGi进行了标准化，所有主要的应用程序供应商都将其运行时基于模块平台，甚至是Sun自己的Glassfish。 甚至还有一个NetBeans端口使用OSGi作为模块系统而不是NetBeans自己的模块。 甚至Maven也在努力成为OSGi运行时。
它只是NIH，许可或其他原因吗？
好问题。 我的理解是，在某些领域，OSGi超出了JVM模块所需的范围（带来了所有相应的复杂性），而在其他领域，它还远远不够。 所以他们之间有很多重叠，但也许还不够。
请参阅此博客条目
引用http://blogs.oracle.com/mr/entry/jigsaw ：
OSGi根本没有与Java语言集成，但是它是在Java SE平台上而不是在Java SE平台上构建的。
最后一个问题可以解决。 Sun现在计划直接与OSGi联盟合作，以便未来版本的OSGi Framework可以充分利用JSR 294的function，从而实现与语言的更紧密集成。
（……）
如果Java SE平台的未来版本包含特定模块系统，那么Sun将提供将Jigsaw模块迁移到该标准的方法。 与此同时，我们将积极寻求与其他模块系统互操作的方法，特别是与OSGi的互操作方式。
Jigsaw团队在Java Posse Podcast 259中概述了Jigsaw项目背后的基本原理以及它与OSGi的关系。
这些项目并没有完全重叠，并且Jigsaw的引入并不是OSGi的丧钟 – OSGi的范围超出了Jigsaw将尝试的范围。 Jigsaw还有很多东西比OSGi团队能够提供（语言，类和JVM实现更改）。 OSGi的设计基于当前的JVM设计 – 对JVM的更改将使每个人受益。
至少，这是我从我读过的内容中得到的 。
查看JavaPosse关于此主题的Mark Reinhold访谈 。
OSGi中缺少一个function。 它不支持作为包子集的模块 。 导出在包级别完成 。
包子集模块是削减JDK依赖关系的唯一方法。 还有一个很好的提示，为什么你应该保持代码清理循环依赖 。
然而，多年来，这种开发方式可能导致API之间以及它们的实现之间的意外连接，从而导致启动时间和内存占用增加。 一个简单的命令行“Hello，world！”程序，例如，现在加载并初始化超过300个单独的类，在最近的台式机上花费大约100ms，尽管还有更多的英雄工程努力，例如类数据共享。 当然，对于更大的应用程序，情况更糟。
编辑：我错了 。 OSGi确实支持拆分包 。