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

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

See this blog entry

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

然而,Java语言已经 而不是从内部。

现在计划直接与 OSGi框架的功能可能完全相同 利用JSR 294和 用语言。

(...)

JavaSE平台包括一个特殊的 模块系统,然后Sun将提供 将Jigsaw模块迁移到 积极寻找解决问题的方法 与其他模块互操作 系统,尤其是OSGi。

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

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

至少,这是我的看法 what I've read .

查看JavaPosse interview with Mark Reinhold 关于这个问题。

OSGi中的缺失 . 是的 不支持作为包子集的模块 . 这个 export is done on the package level

循环依赖

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 .