上个月的一篇新闻谈及了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 更紧密地结合在一起。
评论