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回应道，大公司的支持对规范的成功是重要的，并且尽管Sun对JCP有不成比例数量的控制权，但OSGi的所有成员均一视同仁。

你有什么想法呢？

查看本文来源