JSR277和OSGi会结合吗？

作者 Alex Blewitt 译者 张龙 发布于 2008年5月21日

领域

架构 & 设计,

语言 & 开发

主题

语言 ,

Java ,

技术

标签

OSGi ,

JSR 277 ,

JSR 294 ,

JSR 291

上个月的一篇新闻谈及了JSR277和OSGi（即JSR291）的状况，这在JSR277专家组邮件列表中引发了一场激烈的争论，这场争论是今年以来最为激烈的一场。这之后的主要推动者之一就是Bryan Atsatt，他是JSR277（模块）和JSR294（超级包）的专家组成员。他说JSR277可以胜过OSGi：

初始规范实际上包含两个独立的部分：一个api/框架，一个带有新的分发格式的实现。不幸的是，人们总是不加区别地介绍他们。更遭的是，新的分发格式（“.jam”文件）经常占据上风。
那么JSR 277如何胜过OSGi呢？通过向SE环境提供紧密的集成。其优势主要体现在以下四个方面：

• 正则存储模型
• 编译期依赖的决定
• 跨模块实现的类/资源共享
• 通过命令行的执行

对于现存的OSGi包来说这些都可行。还能更好点吗，哼？也许还有希望。

事实上，Bryan已经在JSR277专家组中发表了大量的评论；他提出规范应该与实现相分离，因为在专家组的草案介绍中它们已经混淆在一起了；另外他又提出Peter Kriens应该加入进来：

专家组已经深陷泥潭了，我们需要重新步入正轨。我提出以下具体步骤：

1. 让Peter Kriens加入到专家组中。Peter在这个领域具有丰富的经验，我相信他很快就会成为一个有价值并且活跃的贡献者。
2. 将设计/讨论/调查的互动过程搬出Sun的办公室，搬到专家组中。
3. 给予专家组更多一手信息（或者至少一个快照）。

当然，看起来很多讨论和实现的决定都是在Sun公司里闭门造车，在决定制订出来后，只是把专家组看作是证明该决定的读者。事实上，以上这两点正是导致Peter Kriens不想加入的罪魁祸首：

然而，JSR 277现在包含两个好的（资源库和语言模块）和一个坏的（JAM）部分。就在JavaOne 2008之前，Stanley发布了一个简短的OSGi互操作性文档。这个文档不仅在细节上非常简略，而且还提到了尚未公布的早期草稿#2（EDR2）的很多地方。我问了专家组成员BJ Hargrave [Equinox - ed]和Richard Hall [Felix - ed]是否他们看到了这个草稿，然而他们也并未看到。最近我在JSR 277邮件列表中抱怨缺乏讨论，看起来工作都在暗地里进行。

在Alex和Stanley介绍JSR 277的过程中，我清楚地认识到幕后已经做了很多工作了；而这一切并未在邮件列表上进行过任何交流。对于在座的各位并不知道几乎所有的东西都没有经过专家组的讨论。如果唯一的选择就是同意Sun在幕后所做的工作的话，那我加入专家组还有什么意义呢？如果在JavaOne演示的尚未发布的EDR2成为JSR 277最终的结果时，有多少东西需要改变？当大部分工作已经完成时，我还需要加入专家组吗？在这种情况下，你能完成多少基本的改变？

我们现在处在一个关键时期。尽管我很想参加关于Java语言模块和仓库的讨论，但是我不能对Java中的模块系统负责，因为它毫无道理地搞出这么多复杂的东西出来。我真心希望Sun能抓住这救命稻草，放弃JAM，采取更为简单的方式在整个系统中使用OSGi元数据。这是我在过去的几个月中得出的结论！

同时，Sun的不断创新也意味着OSGi的交互正在不断进步。Alex Buckley已经加入了277专家组（负责上述的JSR294的简化工作，这真是可喜可贺啊）；同时Mandy Chung已被赋予OSGi互操作性方面的工作。

看起来Sun已经在关注了，还算及时。在今年的JavaOne上，我们报道了基于OSGi的Spring Source应用平台和运行在OSGi上的Glassfish。OSGi最佳实践展示（PDF）激起了人们的兴趣，自从JavaOne后，在论坛和博客上关于包（bundles）的讨论就在持续增长。我们希望JSR277 EDR 2会牢记这些建议并且将OSGi和JSR 277更紧密地结合在一起。

查看英文原文：Are JSR277 and OSGi coming together?

译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。

• 更早的 >