剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
争论：JCP在Java的未来中将扮演什么角色？
作者 Ryan Slobojan译者 王军 发布于 2007年12月18日 下午6时41分
最近，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模块管理系统要像这样处理 —— 他还提出了几个问题：
- Sun无视它签署的JCP法律协定（例如：Apache Harmony）。这摧毁了全部的信任。
- JCP依然存在，以照章批准大公司成员提出的建议。基本上，一个公司提交他们已有的代码，‘专家组’的存在实际上是对其做同行评审。
- JCP或Sun在Java的方向上都没有任何感觉。 在对Java走向何方以及它最终成为什么的问题上应该有明确认识 —— 一个五到十年的远景。
- JCP并不消除重复的JSRs （看看OSGi）。更糟的是，它让更坏的选择得以成功。
- 个人拥有太小的发言权。他们倾向于通过提供创新和分裂来让大公司保持正直。
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。
我在怀疑这个家伙是不是IBM的人
发表人
林 王
发表于
2007年12月18日 下午7时15分
Re: 我在怀疑这个家伙是不是IBM的人
发表人
Xiaogang Guo
发表于
2007年12月19日 上午5时3分
Re: 我在怀疑这个家伙是不是IBM的人
发表人
凉粉 小刀
发表于
2007年12月19日 下午9时1分
Re: 我在怀疑这个家伙是不是IBM的人
发表人
Fengbo Xie
发表于
2007年12月24日 上午10时20分
.gif)
4 条回复
回复