BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

OSGi与JSR 277的争论日趋激烈

| 作者 Ryan Slobojan 关注 0 他的粉丝 ,译者 郭晓刚 关注 0 他的粉丝 发布于 2007年8月14日. 估计阅读时间: 8 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

JSR 277(Java 模块系统)与OSGiJSR 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账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

一群为了钱不要命的疯子! by guannan lee

呵呵!

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT