Sun 对 OSGi 支持者就 JSR 277 所提诸多问题保持沉默

JSR 277 是 Sun 领导的小组，定义了一个官方 JavaTM 模块系统。从 2005 年 6 月开始它就已经活跃起来了，在 2006 年 11 月的时候它交付了一个早期草案。它定位于 J2SE 7.0（Dolphin）的组成部分，然而在立足之前它仍任重道远。不过 JSR 277 是幸运的，Dolphin 看起来要推迟到 2009 年了，以下是来自 today.java.net 上的讨论：

开源 Java 和创建 OpenJDK 基础架构显然耗费了 Sun 的许多精力，这也给我们带来了坏消息。通常 Sun 每 18 个月左右发布一个新的 Java 版本。Java 6 是在 2006 年秋季发布的。因此，最初 Java 7 计划在 2008 年春季发布。但是现在可用的 JDK7 项目构建并没有整合主要的新特性，我们甚至明显连 beta 版都还未关闭。Danny Coward，他将是 Java 7 JSR 的规范领导者，现在表示他们的目标是在 2009 年 1 月发布新版本，从现在算起还有 16 个月。

OSGi ，或 JSR 291 ，是一个 Java 的模块系统，几乎已经是用了 10 年。有许多商业的和免费的可用实现（ Felix 、 Knopflerfish 、 Equinox ）。不像 JSR 277 那样依赖于 Java 7，OSGi 的实现可以运行在 Java 1.3 及 J2ME 基础上。许多系统已经在内部使用了 OSGi，确保 OSGi 和 JSR 277 能够一起工作是 JSR 277 成功的必要条件。

JSR 277 专家组由 Java 生态系统中的几个关键人物组成：Apache、Google、Red Hat、BEA 等等，其中几个对已有 Java 模块系统有丰富的经验。Richard Hall 是 Felix 的创建者，IBM 的代表作是 Equinox 。尽管专家组阵容强大，但是在公开的可读邮件列表上却看不到很多讨论。相反， openjdk.java.net 和另一个邮件列表 modules-dev 担当了这一讨论平台角色，在其上既有讨论也有自动化 bug 报告报表。

有一些问题谈到了 JSR 是否运行平稳。Dalibor Topic 在 1 月份询问：

我也愿意将 JSR 277 的明显处于隐匿状态的专家组的不活跃成员更换为那些真正关心 JSR 的人，即：

• David Bock
• Stuart Halloway
• Doug Lea
• Ted Neward
• Samuel Pullara
• Apache Software Foundation
• Ironflare AB
• Jayasoft
• SAS Institute Inc.

因为自去年 5 月以来，他们并没有在专家组邮件列表上张贴过一条信息（即，8 个月），因此我认为他们可能被安全的 GC 掉了（GC——Garbage Collect，垃圾回收）。 我确信规范领导能够轻易找到感兴趣的专家，他们对这一课题有浓厚的兴趣 ，比如在这一邮件列表读者中间的某些专家。

Dalibor 的说法是对的，JSR 277 专家组的许多成员已经很久没有发言了（尽管实际上 SAP最近评论多了起来）。或许我们更要关注的事实是，专家组不是被要求来评论模块系统本身的发展的，相反，设计是通过把实现文档化而进化的。

被提及的与 OGSi 兼容性问题仍然没有解决之道。去年 6 月，在 JSR 277 专家组列表中贴出了一个问题，询问与OSGi 互操作的情形。从此同样的问题不断被提出，而专家组从没有给出任何接近于兼容的实现，甚至连个可用的暂行方案都没有。在最近在给专家组的帖子中， Stanley Ho 说道：

与其它模块系统的互操作性：正如我们在专家组（EG）中讨论的，我们期望让 JSR 277 与其它模块系统相互操作（比如 OSGi、NetBeans 等等）。已有一些发展中的原型系统来指出它应该如何工作并验证整个方法。当暂行议案就绪后，我将提交给专家组进行审查并讨论。互操作性是在这一 JSR 公开审查之前我想明确解决的问题。

JSR 277 是否将与 JSR 291 兼容还尚待分晓，目前它们并不兼容。如果进度还像去年那么慢，那么它将无法及时包含在明年初将要发布的 Dolphin 版本中。期间，关于 JSR 277 进度的问题仍将存在： Peter Kriens 询问如果以一种更加中立的方式看护 Java 会有什么不同：

我希望我们能够集中于技术问题，这样我们就能够展现为什么（以及在多大程度上）与 JSR 277+294 相比，OSGi 服务平台野心更大，并且为模块性问题提供了更多更高级的解决方案。Sun 因为非技术原因去反抗诸多业界压力及市场分支，而不是和大家一起制定一个适当的标准，这让人感到很悲哀。我不是声称 OSGi 规范就完美无缺，围绕它仍需做不少工作。可是，它们是成熟的、经过检验的、有大批用户、并且看起来比 JSR 277 现在试图实现的功能（学习曲线过于陡峭）还要提供更多的功能。当 Java 社区以更加独立的方式去看护，这种情形还会出现吗？

与此同时 Neil Bartlett 问到这一问题是否属于规范领导的职权范围：

因此，在将近一年之后，暂行方案仍“在进行中”，没有指出进展了多少、还需多少工作。很明显，Sun 仍在做些事情，因为针对 OpenJDK 模块开发组件的众多活动被一一记录下来了。但是他们不愿意询问 JSR 277 专家组的意见或寻求他们的帮助，尽管“在理论上，JSR 277 专家组是世界上最重要的模块系统和 OSGi 专家”。

1 月份，Dalibor Topic 提议对 JSR 277 专家组成员进行一次垃圾回收，他们中许多人已经不活跃了。我非常同意，就让我们从规范领导开始吧。

InfoQ 不会对 Stanley Ho 的观点做出评论。你有什么想法？JSR 277 应该兼容 OSGi 吗？

查看英文原文： Sun’s Silence on JSR 277 Leaves Many Questions from OSGi Supporters and Few Answers