上上周，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
活动推荐：
2023年9月3-5日，「QCon全球软件开发大会·北京站」 将在北京•富力万丽酒店举办。此次大会以「启航·AIGC软件工程变革」为主题，策划了大前端融合提效、大模型应用落地、面向 AI 的存储、AIGC 浪潮下的研发效能提升、LLMOps、异构算力、微服务架构治理、业务安全技术、构建未来软件的编程语言、FinOps 等近30个精彩专题。咨询购票可联系票务经理 18514549229（微信同手机号）。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论