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

作者 Rob Thornton 译者 Jason Lai 发布于 2007年9月18日

领域

过程 & 实践,

语言 & 开发

主题

JSR 291 ,

JSR 277 ,

JCP标准 ,

JCP ,

Java ,

语言 ,

编程 ,

OSGi ,

社区

分享到

上上周，JSR 291的规范领导人及JSR 277专家组（Expert Group）成员Glyn Normington以博客文章的形式发布了JSR 277、JSR 291和OSGi规范相关讨论的最新保留条款。到目前为止专家组尚未收到技术说明草案（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