OSGi 与 JSR 277 的争论日趋激烈

JSR 277 （Java 模块系统）与 OSGi （ JSR 291 ）的争论再次变得白热化， JSR 316 （Java EE 6）的提交又一次引燃了关于 OSGi 与 JSR 277 互相重叠的争论。InfoQ 整理总结了其中的若干观点和论据。

Peter Kriens 写了一篇博客文章讨论 Java EE 6 中对 Profile 的使用，并展示了如何用组件结构来代替模块系统作为 Java EE 6 的基础。Kriens 还质疑了 Java EE 6 规范中对 JSR 277 的使用，他说：

JSR 316 仅仅在规范的需求部分，以一种相当间接的方式提到了 JSR 277。大致上是说 JSR 277 正在制定中，他们将推迟任何决定，直到 JSR 277 完成。看上去颇有道理，因为从编号上看 277 比 291 更老也更成熟？但实际上，277 仍然处在草案复审阶段，而 291 已经最终发布，因为 291 的基础是从 1999 年发布至今，已经经过 4 个主要修订版的非常成熟的 OSGi 规范。那么，应该有别的理由不提 JSR 291 吧？也许 277 提供了 291 缺少的特性？嗯，没有。从 JSR 277 规范的需求看，谁也没法说它的目标比 JSR 291/OSGi 更加远大：没有动态、没有类空间一致性、没有卸载、没有包引用等等。277 的初步草案仍然处在一种过于简单化的程度。即便是 277 唯一比 291 强的 Repository，也仍然有许多晦涩不明之处。JSR 277 最近开放了邮件列表，从里面的讨论中可以看出，似乎他们仍然被一些基本的模块性问题所困扰。不过，幸运的是，JSR 277 专家组已经承诺让 277 的模块系统与 JSR 291/OSGi 互操作。这就消除了选择 OSGi 的最后一丝风险，更不用提今天就可以在各种 VM（从 1.2 到 6，以及嵌入式设备）上运行 OSGi 的额外好处，而 JSR 277 只能运行在 2008 年下半年才会发布 Java 7 上。那么，为什么 JSR 316 要停下来等？我们已经有一个完美的方案，而且 JSR 277 承诺将会兼容？

Alex Blewitt 也质疑了 Java EE 6 选择 JSR 277 的决定：

提交的草案声称：

为了更好地支持这个平台在扩展性方面的目标，应该有一个更加宽泛的模块概念。这项工作正由“JSR 277——Java 模块系统”展开，它的目标是 Java SE 7。我们预期 Java EE 7 将建立在这项技术的基础上，因此我们将推迟任何可能与将来的版本冲突的技术规范。

也就是说，他们选择了 JSR 277 而非 JSR 291，并且拒绝在 JSR 277 随 Java 7 发布之前考虑任何其它选择。

InfoQ 也询问了 Eric Newcomer 是否认为 SUN 应该接受 OSGi：

绝对应该，绝对合理。更重要的问题是关于 Java 的未来，关于 SUN 是会拥抱 OSGi 还是继续对抗，如果他们继续对抗 OSGi，对 Java 又会有什么影响。根据我最近有限的 OSGi 经验来说，它在许多方面都给 Java 带来了显著的改进——模块性、版本、增强的类装载。Sun 投票反对 JSR 291，不过 JSR 291 仍然获得了通过，正式成为 JSE 的一部分。不过这已经表明了 Sun 的立场。JSR 277 是由 Sun 提案的，内容是 Java 模块性，这看起来明显跟 OSGi 重叠。Sun 有过很好的机会拥抱 OSGi 并以之为基础构造 Java 7，不过，虽然没有正式的声明，但看上去他们更倾向于重复 OSGi 的工作而不是拥抱 OSGi。

我期望 Sun 能尽快理性地对待 OSGi。不过，也许 Sun 继续站在 OSGi 的对立面反而更好，因为至今 OSGi 都发展得很好。

Hani Suleiman ，JSR 291 专家组的成员之一，对这场争论有不同看法。在回答关于 JSR 277 和 OSGi 有什么共同基础时，他说：

[……]JSR-277（在某种程度上）是一个共同的基础。它从 JDK 这一面着手解决问题，这让 OSGi 和其他类似方案（Maven、Ivy 等）的任务变得更加容易。组件包（Bundle）/ 模块成为 JVM 层次的一等公民。除此之外，（OSGi 或其它）框架可以按照自己的意思添加任何增值功能。277 并没有限制。OSGi 支持者们感到不高兴只是因为基础标准用的不是他们的实现，而且还考虑了很多其它方面的东西。

用 Hibernate 来打比方，请想象这样的情形：JBoss 一直攻击 JPA 规范，说它是重新发明轮子，所有人都应该把 Hibernate 当作标准。这就是 OSGi 支持者们正在做的。

其他人，如 Neil Bartlett ，也就 JSR 277 专家组的讨论内容提出了他们的担心：

请看看 JSR 277 的专家组邮件列表，它已经向公众开放（虽然是只读的）。从这些讨论来看，很难认为他们有倾听两位 OSGi 专家（Glyn Normington 和 Richard Hall）的意见。在 JSR 277 草案的规范定义和应用举例中，有很多地方跟 OSGi 是不可调和的：Sun 拒绝学习任何 OSGi/JSR 291 的经验。OSGi 支持者们并不是因为我们最中意的模块系统没被选中就大发牢骚。这太孩子气了。我们鼓噪是因为原则问题，JSR 277 这个模块系统正在迈向失败！如果在 JVM 里绑死了一个残缺的模块系统，这会给整个 Java 社区造成巨大的破坏。

Chris Custine 从另一个角度看这场争论的起源：

我认为 Sun 和 OSGi 的激烈冲突纯粹是关于控制权和许可证的政治斗争。根本和技术无关！Java 社区的政治又一次无视了每个理智的人都具备的常识和逻辑。我一向非常期待 Java 能够再次复兴它在创新和进化上的能力，但正是这些东西让我担心……

Glyn Normington ，JSR 277 专家组成员和 JSR 291 的规范带头人，试图谨慎地表达他的观点。除了两者的特性对照，Normington 还就争论中涉及的问题写了一篇详细的介绍。他解释说“这两项JSR 的目标是非常不同的，虽然背后的概念很接近。JSR 277 和294 是在Java SE 平台之中加入基本支持；而JSR 291 是纯Java 的，它建立在Java 平台之上”。

Normington 认为在 JSR 277 中重用 OSGi 并不容易，他也讨论并推翻了放弃 JSR 277 的想法，最后提出了他认为最合适的解决方案：

最佳方案很清楚：JSR 277 应该接受 JSR 291，为此应该在 JSR 294 里加强语言和 VM 上的支持，并且加入 JSR 277 的 Repository 架构。这样可以让 JSR 277 的进程提前数年，还保证了 JSR 277 和 JSR 291 之间完美的互操作性。但要想实现这个最佳方案，需要 Sun 转一个 180 度的大弯。也许，只是也许，Sun 为了保证 Java 的成功，终究会做这件事。也许，只是也许，将来 Java 社区可以回顾今天，并且模仿丘吉尔的话说：“在穷尽了所有选择之后，总是可以指望 Sun 做正确的事”。

社区里面对于什么是这个困境的最佳解决方案肯定也是争论不休——您的看法呢？

查看英文原文： OSGi and JSR 277 debate continues to grow