JSR277 和 OSGi 会结合吗？

上个月的一篇新闻谈及了 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?