OSGi与JSR 277的争论日趋激烈

作者 Ryan Slobojan 译者 郭晓刚 发布于 2007年8月12日

领域

语言 & 开发,

过程 & 实践

主题

JCP标准 ,

社区 ,

Java

标签

OSGi ,

JCP ,

Java EE ,

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

译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。

1. 返回顶部

   一群为了钱不要命的疯子！

   发表人 guannan lee

   呵呵！

   回复

• 更早的 >