Java 当每个人都在OSGi上进行标准化时，为什么Sun会发明另一个模块系统？

Sun在模块化JDK方面投入了大量精力，以的形式出现，并暗示它也应该是其他Java开发人员选择的模块格式。唯一值得注意的使用此功能的玩家是NetBeans（和衍生应用程序）

另一方面，行业已经围绕OSGi进行了标准化，所有主要应用程序供应商都将其运行时基于模块平台，甚至Sun自己的Glassfish。甚至有一个NetBeans端口可以使用OSGi作为模块系统，而不是NetBeans自己的模块。甚至Maven也在努力成为OSGi运行时

这仅仅是NIH、许可证或其他原因吗？

引用：

OSGi根本没有与 然而，Java语言已经 构建在JavaSE平台之上，而不是 而不是从内部

最后一个问题可以解决。太阳 现在计划直接与 OSGi联盟使未来版本 OSGi框架的功能可能完全相同 利用JSR 294和 从而实现更紧密的整合 用语言

（……）

如果和何时为未来版本的 Java SE平台包括一个特定的 模块系统，然后Sun将提供 将Jigsaw模块迁移到 这个标准。在此期间，我们将 积极寻找解决问题的方法 与其他模块互操作 系统，尤其是OSGi

---

好问题。我的理解是，在某些领域，OSGi远远超出了JVM模块所必需的功能（带来了所有相应的复杂性），而在其他领域，它做得还不够。所以它们之间有很多重叠，但可能还不够

---

OSGi中缺少一项功能。它不支持作为包子集的模块。这个

包子集模块是解决JDK依赖性难题的唯一方法。还有一个很好的提示，说明为什么您应该保持代码中没有循环依赖项

---

编辑：我错了

Jigsaw团队在年概述了项目Jigsaw背后的基本原理及其与OSGi的关系

这些项目并没有完全重叠，Jigsaw的引入并没有敲响OSGi的丧钟——OSGi的范围超出了Jigsaw的任何尝试。Jigsaw还有比OSGi团队能够提供的更多的功能（语言、类和JVM实现更改）。OSGi的设计基于当前的JVM设计——对JVM的更改将使每个人受益

---

至少，这是我的观点。

查看关于这个主题的JavaPosse。

你的问题中的“暗示它应该……”部分有参考资料吗？你链接的页面有一个研究项目主页的基调，而不是用来介绍Sun希望每个人都使用的关键技术。啊，这是我一直在寻找的博客条目，但找不到：）问题是这没有发生。JSR294实际上是死的，与拼图无关（反之亦然）。module关键字最终能否被使用在某种程度上与模块系统本身的问题是正交的。@AlBlue-JSR294的状态也让我感到困惑。JCP页面将其列为非活动，但工作（显然）作为Jigsaw的一部分正在继续。我认为你错认为他们是无关的。拼图页上写着：与JSR 294工作文件的关系应该被视为材料的草稿，有待进一步讨论。例如，拼图页上写的内容和294小组（应该）正在做的工作有区别。看起来Sun放弃了JSR，只是做了自己的事情；邮件列表已经死了，最后一条消息是“去讨论Jigsaw邮件列表上的Jigsaw”。我没有遇到包子集模块的概念-你知道有任何博客或文章讨论过这一点吗？“4.一个Java包中的不同类型必须可能属于不同的模块。”正如编辑所说，这是错误的。事实上，开源JVM Harmony已经使用OSGi清单来表示模块之间的中断，包括那些带有乔治亚结的模块。我认为拆分包是一个bug，而不是一个特性。当然，按照JDKAPI的发展方式，如果您想避免重大（不兼容）重构，就需要支持它们。但是，如果有人从头开始设计java.*包，我想她会沿着模块边界对齐包。子集包是否意味着只导出希望导出的包中的一些类，而不是所有类？