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

Question

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

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

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

Answer 1

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

然而，OSGi 根本没有与 Java 语言集成，它是在 Java SE 平台之上而不是在其中构建的。

最后一个问题可以解决。Sun 现在计划直接与 OSGi 联盟合作，以便 OSGi 框架的未来版本可以充分利用 JSR 294 的特性，从而实现与该语言的更紧密集成。

(...)

如果 Java SE 平台的未来版本包括特定的模块系统，那么 Sun 将提供一种将 Jigsaw 模块迁移到该标准的方法。与此同时，我们将积极寻求与其他模块系统互操作的方法，特别是与 OSGi。

Answer 2

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

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

至少，这是我从我读过的内容中得到的。

Answer 3

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

请参阅此博客条目

Answer 4

OSGi中缺少一项功能。它不支持作为包子集的模块。导出是在包级别完成的。

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

然而，多年来，这种开发方式可能会导致 API 之间以及它们的实现之间出现意想不到的连接，进而导致启动时间和内存占用增加。一个简单的命令行“你好，世界！” 例如，程序现在加载和初始化超过 300 个单独的类，在最近的台式机上花费大约 100 毫秒，尽管还有更多的工程努力，例如类数据共享。当然，对于更大的应用程序，情况会更糟。

编辑：我错了。OSGi 确实支持拆分包。

Answer 5

查看 JavaPosse对 Mark Reinhold 的采访。