当每个人都对 OSGi 进行标准化时，为什么 Sun 还要发明另一个模块系统？
Sun 投入了大量精力以 Jigsaw 的形式对 JDK 进行模块化，并暗示这一点它也应该成为其他 Java 开发人员选择的模块格式。使用此功能的唯一著名参与者是 NetBeans（及其衍生应用程序）。
另一方面，业界已经围绕 OSGi 进行了标准化，所有主要应用程序供应商都将其运行时基于模块平台，甚至包括 Sun 自己的 Glassfish。甚至还有一个 NetBeans 端口可以使用 OSGi 作为模块系统，而不是 NetBeans 自己的模块。甚至 Maven 也在努力成为 OSGi 运行时。
仅仅是 NIH、许可还是其他原因？
Sun is putting a lot of effort behind modularising the JDK in the form of Jigsaw, and insinuating that it should be the module format of choice for other Java developers as well. The only notable player who is using this is NetBeans (and derivative applications).
On the other hand, the industry has standardised around OSGi, with all of the major application vendors basing their runtimes on the module platform, even Sun's own Glassfish. There's even a port of NetBeans to use OSGi as the module system instead of NetBeans own modules. Even Maven is working towards becoming an OSGi runtime.
Is it just NIH, licensing, or another reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
引用 http://blogs.oracle.com/mr/entry/jigsaw：
Citing http://blogs.oracle.com/mr/entry/jigsaw:
Jigsaw 团队在 Java Posse Podcast 中概述了 Jigsaw 项目背后的基本原理以及它与 OSGi 的关系259。
这些项目并不完全重叠，Jigsaw 的引入并没有敲响 OSGi 的丧钟——OSGi 的范围超出了 Jigsaw 的任何尝试。 Jigsaw 还提供了 OSGi 团队无法提供的更多内容（语言、类和 JVM 实现更改）。 OSGi的设计是基于当前的JVM设计——对JVM的改变将使所有人受益。
至少，这是我从我读过的内容中得到的内容。
The rationale behind project Jigsaw and how it relates to OSGi was outlined by the Jigsaw team in Java Posse Podcast 259.
These projects do not entirely overlap and the introduction of Jigsaw does not sound the death knell for OSGi - the scope of OSGi goes beyond anything Jigsaw will attempt. There's much more to Jigsaw than the OSGi team is in a position to provide (language, class and JVM implementation changes). The design of OSGi is based on the current JVM design - the changes to the JVM will benefit everyone.
At least, that is my take from what I've read.
很好的问题。我的理解是，在某些领域，OSGi 远远超出了 JVM 模块所需的范围（及其带来的所有相应的复杂性），而在其他领域，它还不够。所以它们之间有很多重叠，但可能还不够。
查看此博客条目
Excellent question. My understanding is that in some areas OSGi goes way beyond that which is necessary for JVM modules (with all the corresponding complexity that brings) whilst in other areas it doesn't go far enough. So there's a lot of overlap between them but perhaps not enough.
See this blog entry
查看 JavaPosse Mark Reinhold 就该主题的采访。
Check out the JavaPosse interview with Mark Reinhold on the subject.
OSGi 中缺少一项功能。它不支持作为包子集的模块。 导出是在包级别完成的。
包子集模块是解决 JDK 依赖项的棘手问题的唯一方法。并很好地提示了为什么您应该保持代码中没有循环依赖。
编辑：我错了。 OSGi 确实支持拆分包。
One feature is missing in OSGi. It does not support modules that are subsets of packages. The export is done on the package level.
Package subset modules are the only way to cut the Gordian knot of JDK dependencies. And a nice hint why you should keep your code clean of circular dependencies.
Edit: I was wrong. OSGi does support split packages.