原型缺乏导致 JSR 277 和 JSR 291 互操作性受到威胁

  • Rob Thornton
  • Jason lai

2007 年 9 月 18 日

话题:Java社区语言 & 开发文化 & 方法

上上周,JSR 291 的规范领导人及 JSR 277 专家组(Expert Group)成员Glyn Normington 以博客文章的形式发布了JSR 277JSR 291OSGi规范相关讨论的最新保留条款。到目前为止专家组尚未收到技术说明草案(strawman),对此 Normington 表示忧虑,并且他也担心专家组最终无法对这份技术说明草案进行详细讨论,并进行相应变更,而是以草案为准草草定案。

Normington 和 Bryan Atsatt(JSR 277 专家组成员)在上上周向 JSR 邮件列表发送了一封邮件,了解技术说明草案的状态并且询问该草案何时可以提交评审。JSR 277 的规范领导人 Stanley Ho 就此回复到

工作尚在进行中,目前我们也在着手原型构造工作,以便了解规范该如何工作并且也可以验证整个方法的正确性。一旦技术说明草案准备就绪,我会马上提交,让专家组评审和讨论。互操作性正是我希望在这个 JSR 面向公开评审之前解决的问题。

对于 JSR 277 和 299 是否会整合,Normington 表示疑虑。他写到:

目前在这方面,不管是专家组还是更大范围的社区都还看不见任何相关东西。这个结果很尴尬,因为已经有一个 modules 项目在 OpenJDK 上建立起来了,因此我更希望这样的原型构造工作能在一个分支或者子目录下进行,这样才方便从其他人那儿获得早期反馈。

目前的情况很是令人担心,因为在 JSR 277 专家组的 OSGi 专家 Richard Hall 和我自己,还有其他在 JSR 291 专家组的人现在都无法参与帮忙。到了我们真正看到技术说明草案的时候,要进行重大变更可能已经太迟了。

Alex Miller 也加入讨论,号召整个 Java 社区更多地参与到这个讨论中来,因为这样会给 Java 平台带来分支。

如果我们能正确地解决这个问题,它会给我们带来支持,并且让我们建立 CPAN 或者 Ruby Gems 的真正 Java 等价版本。假如我们选择了错误的方法去做,那么部署和版本管理以及 JAR“地狱(hell)”会变得比目前还要难以处理。使之能向正确方向发展是至关重要的,因为这会被深深烙进 Java 语言、类库和工具中。

此外,Miller 也倡议Java Posse能够更深入地了解一下 JSR 规范集目前的情况。Java Posse 在最近提到数次此事,并在他们的讨论组中引发了一些讨论。Neil Bartlett 怀疑技术说明草案是否是因为互操作性问题实际上比 Sun 透露的更加难以解决而不得不推迟:

OSGi 模块是否能与 JSR 277 模块干净地互操作呢?我一直在跟进 JSR 277 专家组的邮件列表,但看起来事情并不像想象中那么能让人看到希望。在 JavaOne 大会上,整个专家组齐聚一堂,Stanley Ho(规范领导人)向专家组承诺 Sun 会交付一个互操作性方面的“技术说明草案”设计方案。然而,他们仍然没能搞出什么名堂来给专家组的其他人看,而且甚至还拒绝专家组的其他成员参与技术说明草案的设计。我强烈地怀疑——其他参与 OSGi 的人也抱有同样的想法——这两套模块系统设计实在是太大相径庭了,所以 Sun 现在在抓耳挠腮就是不知道如何才能交付这个互操作技术说明草案。

欲了解这个论战的一些前期历史,您可以参阅 InfoQ 中文站先前的相关报导

查看英文原文:JSR 277 and JSR 291 Interoperability threatened by lack of a prototype

Java社区语言 & 开发文化 & 方法