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
评论