上个月的一篇新闻谈及了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 更紧密地结合在一起。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论