当每个人都对 OSGi 进行标准化时，为什么 Sun 还要发明另一个模块系统？答案

【问题标题】：Why is Sun inventing another module system when everyone has standardised on OSGi?当每个人都对 OSGi 进行标准化时，为什么 Sun 还要发明另一个模块系统？
【发布时间】：2010-12-23 22:57:48
【问题描述】：

Sun 在以 Jigsaw 的形式模块化 JDK 方面付出了很多努力，并暗示它也应该是其他 Java 开发人员选择的模块格式。唯一值得注意的玩家是 NetBeans（和衍生应用程序）。

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

仅仅是 NIH、许可还是其他原因？

【问题讨论】：

您对问题的“暗示它应该......”部分有参考吗？您链接的页面具有研究项目主页的基调，而不是用于介绍 Sun 希望每个人都使用的关键技术。

标签： java module osgi java-platform-module-system

【解决方案1】：

引用http://blogs.oracle.com/mr/entry/jigsaw：

OSGi 根本没有与然而，Java 语言已经构建在 Java SE 平台之上，而不是而不是从里面。

最后一个问题可以解决。太阳现在计划直接与 OSGi 联盟让一个未来的版本 OSGi 框架的利用 JSR 294 的特性和从而实现更紧密的集成与语言。

(...)

如果未来版本的 Java SE 平台包括一个特定网络模块系统，那么 Sun 将提供一个意味着将 Jigsaw 模块迁移到那个标准。与此同时，我们将积极寻求途径与其他模块互操作系统，尤其是 OSGi。

【讨论】：

啊，这就是我一直在寻找但找不到的博客条目：)
问题是这并没有发生。 JSR294 实际上已经死了，并且与 Jigsaw 无关（反之亦然）。模块关键字最终是否可以被使用在某种程度上与模块系统本身的问题是正交的。
@AlBlue - JSR294 的状态也让我感到困惑。 JCP 页面将其列为非活动状态，但工作（显然）作为 Jigsaw 的一部分仍在继续。我认为您误认为它们无关。 Jigsaw 页面显示：与 JSR 294 的关系 此处发布的工作文档应被视为材料草稿，需要在该 EG 内进一步讨论。 openjdk.java.net/projects/jigsaw
Jigsaw 页面的内容与 294 小组正在（应该是）工作的内容有所不同。看起来 Sun 正在放弃 JSR，只做自己的事情；邮件列表像渡渡鸟一样死了，最后一条消息说“去讨论 Jigsaw 邮件列表上的 Jigsaw”。

【解决方案2】：

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

See this blog entry

【讨论】：

【解决方案3】：

OSGi 中缺少一个功能。它不支持作为包子集的模块。 export is done on the package level。

包子集模块是切断 JDK 依赖关系的致命结的唯一方法。还有一个很好的提示，为什么你应该保持你的代码没有循环依赖。

Over the years, however, this style of development can lead to unexpected connections between APIs—and between their implementations—leading in turn to increased startup time and memory footprint. A trivial command-line “Hello, world!” program, e.g., now loads and initializes over 300 separate classes, taking around 100ms on a recent desktop machine despite yet more heroic engineering efforts such as class-data sharing. The situation is even worse, of course, for larger applications.

编辑：我错了。 OSGi does support split packages.

【讨论】：

我没有遇到包子集模块的概念——你知道讨论这个的博客或文章吗？
"4. 一个 Java 包中的不同类型必须有可能属于不同的模块。" altair.cs.oswego.edu/pipermail/jsr294-modularity-observer/…
正如编辑所暗示的，这是错误的。事实上，Harmony 是一个开源 JVM，已经使用 OSGi 清单来表示模块之间的中断，包括那些带有 Geordian 结的模块。
我会说拆分包是一个错误，而不是一个功能。当然，JDK API 的发展方式，如果你想避免重大的（不兼容的）重构，你需要支持它们。但如果有人要从头开始设计 java.* 包，我想她会沿着模块边界对齐包。
子集包是否可能意味着只导出一个包中希望导出的部分类而不是所有类？

【解决方案4】：

Jigsaw 团队在 Java Posse Podcast 259 中概述了 Jigsaw 项目背后的基本原理以及它与 OSGi 的关系。

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

至少，这是我对what I've read 的看法。

【讨论】：

【解决方案5】：

查看有关该主题的 JavaPosse interview with Mark Reinhold。

【讨论】：