争论：JCP 在 Java 的未来中将扮演什么角色？

最近， Alex Blewitt 称 Java Community Process（JCP）已经死了，将之喻为无头鸡：“自己还没有意识到，仍在四处奔跑，但实际已死了”。由此引发一场关于 JCP 作用，及其在 Java 的未来中将扮演什么角色的争论。

Alex Blewitt 在博文中指出了关于 Java 和 JCP 的几个利害关系：

• JCP 导致了更大的 JVM，几乎没有移除什么，反倒是加入了不少东西
• 现在，VM 要求所有东西都要出现，没有什么东西可以被移除—— Consumer JRE 是一个好的开端，但它只是将 jar 的下载延迟到需要的时候，而不是一开始就把它们全部下载——整个 JRE 仍然需要下载
• Java 需要一个新的模块系统，它允许动态的、按需的组件下载，这样不用下载那些从不使用的内容
• 尽管一些模块系统在现今 Java 上存在并发挥作用，但是一些正在为 Java 7 创建的新内容可能比现有解决办法更加臃肿且功能更少，而且可能会被大多数实现者（类似 java.util.logging 和 XML 解析器）所取代
• 对 Java 的演变管理工作几乎没什么帮助（无论是减少还是增加）
• 微软正在语言前线打击 Java —— .Net 有好些正被大量开发者日常使用的语言，Java 实际上只有 Java 语言，其它的还是“小鱼苗”——Java 在一些语言特性（如范型、延续（continuation）和函数即数值（functions as values））上还正在扮演追随者。
• 尽管对于象 Scala 这样的跨 VM（cross-VM）语言有一些适当的机遇，但是最有可能的未来之路是 Google 的 GWT 和 Android 的方式——复用 Java 语言，但瞄准 Java API 的一个子集，并发展 JCP 之外的产品以避免不这样而招致的额外包袱
• J2ME 是个灾难 —— 各种设备存在着严重的分裂，而且 J2ME 无法处理像蓝牙、USB 或拨号器这样有用的东西
• JSRs 是个重负，只是让一个已经臃肿的平台更加臃肿——JCP 阻碍了轻量级、模块化方式和在此之外的真正创新

Blewitt 还指出:

JCP 不关乎于社区，它关乎于控制。通读任一 JSRs，有一节是“为什么不用现有系统来解决”。通读它们是一个市场营销的练习；这儿总是没有真正的理由，而只是说‘我们可以做的更好 / 不同的 / 较小的 / 更快的’。在这种情况下，实际发生的是该规范的领导们没有丝毫兴趣在现有基础上进行构建；他们想要得到他们自己版本的代码库（不论是真实的或被提议的），而且理由基本上都是‘因为我们没有编写它’。那些所谓的‘专家小组’只不过是对开发者（通常就是 JSR 的提交者）进行同行评审，对实际代码开发毫无影响。（一般情况下，JSR 的提交者将只给代码开发者提供资助，而不是寻求专家小组的帮助，这样他们能拥有过程的所有知识产权）。换句话说，你想做的任何事都要得到他们的支持同意

其他人评论说： Google 应该领导 Java 的发展, 或 Java 将会很快被一个真正的并行语言取而代之. 然而一些人担心模块化会引起这个平台的分裂。

就在上帖发布的同一天， JRS 275（计量和单位）的联合带头人 Jean-Marie Dautelle 为 JCP 征求来自社区的反馈意见和问题：

• Alexander Hristov 要求公开辩论，开放邮件列表并公开会议
• Robert Cooper 指出： C 字母在 JCP 中代表着社区，但委员会和公司利益似乎比社区利益更重要
• Terrence Barr 要求更多个人和小公司的参与，更多开放源代码的兼容性（如减少 NDAs 和私有组件），以及 JRS 专家组成员能更公开接近并接受公众意见
• Brendon McLean 认为 JSR 296 ( Hans Muller 领导的) 是 JSR 正确做事的一个很好例子：建议 JSR 始终包含一个领域专家，开放源代码解决方案始终得到认真的考虑，所有 JSRs 在公开化和社区参与性方面都参照 296 的领导方式
• Patrick Wright 补充说：来自个人和小团体的输入与公司的输入一样重要，而且 JCP 应承认如 Spring 和 Apache Commons 这样事实上的标准

Dautelle 的问题也引起了 JSR 310 （日期和时间 API）联合带头人 Stephen Colebourne 的长篇大论。Colebourne 问道:

这个问题引出了更广泛的 Java 监管问题。Java 现在是开源的，但我们现在还没有真正清楚这是如何运作或影响 JCP 的。特别是，谁是监查 Java 发展和其未来方向的‘建筑师’？是 Sun 公司中某人？一个隐藏的神奇过程？或者就是撞大运？

Colebourne 想知道谁决定了哪些语言变化加入到 Java 7，核心库的变化是如何发生的，以及为什么 JSR 277 模块管理系统要像这样处理 —— 他还提出了几个问题：

1. Sun无视它签署的 JCP 法律协定（例如：Apache Harmony）。这摧毁了全部的信任。
2. JCP 依然存在，以照章批准大公司成员提出的建议。基本上，一个公司提交他们已有的代码，‘专家组’的存在实际上是对其做同行评审。
3. JCP 或 Sun 在 Java 的方向上都没有任何感觉。 在对 Java 走向何方以及它最终成为什么的问题上应该有明确认识 —— 一个五到十年的远景。
4. JCP 并不消除重复的 JSRs （看看 OSGi）。更糟的是，它让更坏的选择得以成功。
5. 个人拥有太小的发言权。他们倾向于通过提供创新和分裂来让大公司保持正直。

Colebourne 也提出了几种解决方案，例如一个将公布 Java 五到十年远景的架构组，一个规模更大、更自主的 JCP 执行委员会，给 JSR 成员付工资，以及一个针对 Apache Harmony 正确的 TCK 技术兼容包。另一种选择是淘汰 JCP，并将 Java 重新定义为建立在一个内核之上基于 OSGi 的模块化 VM——厂商可以随意混合匹配，市场将决定谁是赢家。Patrick Wright不赞同这些观点，他指出在Apache-Sun Harmony 的争论中，只有Apache 公布了他们的一面之辞。Wright 还质疑一个五到十年的远景到底能对语言发展的高速步伐提供多大的价值。

Peter Kriens 也在辩论中进行了权衡，他同意Colebourne 的分析，但不同意其解决方案。Kriens 还提出了一个新的问题——什么更切合实际，是实现还是规范？Kriens 指出规范允许有多个针对不同需求的实现，它允许通过平衡众多组织的需求而保持中立。缓慢的标准化进程考虑到了思考解决方案的实际时间，知识产权的问题也将更容易处理。 Dalibor 主题回应说 JCP 和 OSGi 都被大公司过多控制，而且规范被私有组件所拖累——尽管他们都值得拥有。Kriens 回应道，大公司的支持对规范的成功是重要的，OSGi 的所有成员均被同等相待，尽管 Sun 对 JCP 有相当大的控制权。

你有什么想法呢？

查看英文原文： Debate: What role will the JCP play in Java’s future? - - - - - -

译者简介：王军，长期从事软件开发工作，实际项目偏重于 JBOSS 平台上构建网管软件。对于性能测试工具有较多的关注，关心软件技术和相关工具的动态，将其中相对成熟的技术和工具应用到实际的项目之中。长期担任技术管理和项目管理工作，一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。