OSGi与JSR 277的争论日趋激烈

作者 Ryan Slobojan 译者 郭晓刚 发布于 2007年8月12日 下午10时44分

社区

Java

主题

JCP标准,

社区

标签

OSGi,

JCP,

JSR 277,

Java EE

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

1. 返回顶部

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

   2007年11月29日 上午7时53分 发表人 lee guannan

   呵呵！

   回复

• 更早的 >