Sun 与 Apache 的分歧使 Java 7 公告黯然失色

  • Charles Humble
  • 崔康

2009 年 4 月 6 日

话题:Java语言 & 开发架构

Sun 公司的 Mark Reinhold 在 OpenJDK 网站上发布了一个 JDK 7 的更新日程表,同时列出了核准的功能清单。目前的 build 处于里程碑 2,包括新的 Garbage First 垃圾收集器和 I/O APIs[JSR 203]。里程碑 3,预计在五月份的 JavaOne 大会的时候会完成,将通过 invokedynamic 字节码指令添加对动态类型语言的 VM 支持 [JSR 292]。Java 7 其他的显著功能包括添加 Java 6 update 10 的向前兼容到 OpenJDK(里程碑 4),目前按兵不动的 Swing Application Framework[JSR 296](里程碑 5,预计在秋天),另外还有标准化模块(JSR 294)和 Jigsaw 项目。值得注意的是,目前的路线图中没有新的 Date 和 Time API[JSR 310],Beans 验证 [JSR 303] 和 Beans 绑定 [JSR 295]。

项目 Coin

针对小的语言变化提议,也收到了大量的建议,Joseph Darcy 在其

博客

上突出强调了六个具有竞争力的提议:

  1. 自动化资源管理。由 Joshua Bloch 提交,一个 ARM 块是 try 语句的一种形式,声明若干个资源,并且限制在该语句中。当语句结束,不论是正常方式还是暴力方式,所有相关的资源都自动关闭。这减少了手动关闭资源的需要,在现实中非常容易出错。据 Bloch 所说,连 JDK 自己的 close 方法都有三分之二实现的不正确。

  2. Elvis 和其他 null-safe 操作符。由 Stephen Colebourne 提交,原始想法出自 Neal Gafter,目的是解决一些 NullPointerException 异常的常见问题,使其可以忽略对象的 null 检查。
  3. 改进异常处理。由 Neal Gafter 提交,这个提议包括处理多种异常的 catch 语句块和改进重新抛出的异常的检查。
  4. 改进对通用实例创建的类型推断。由 Jeremy Manson 提交,该建议提出增加对类实例创建表达式的有限类型推断。例如取代书写:Map
  5. 简化 Varargs 方法调用。由 Bob Lee 提交,建议修改编译器针对方法结合 varargs 和非具体化数组类型时抛出的警告,把该警告从调用处移到方法声明处。
  6. switch 语句的字符串。由 Joseph Darcy 提出,建议增加对 switch 语句的字符串支持。

Sun 针对 Java 7 的 JDK 将是它首次基于 OpenJDK,虽然其实现仍然依赖于某些非开源组件。同时,Sun 开发 Java 产品的方式也在改变,不依赖 JSR,而是功能不断增加,最后完成时再标准化。项目 Jigsaw、JavaFX 和 Java SE 7 都是按照这种方式开发的。Mark Reinhold这样写到

“JDK 7 项目创建了一个基于 Java SE 7 的原型——不论是不是会最终采用。当 SE 7 平台 JSR 被提交之后,JDK7 开发的功能才会被列入其中,除了那些虚拟机(VM)级别的或者特定实现的。”

OpenJDK 项目和针对 Java 7 透明的功能集、日程表的结合比我们以前看到过的历次修订都要开放的多,但是来自 Apache 的 Stephen Colebourne 对这种变化非常担忧,认为可能导致 Java 7 没有正式规范,而是只有一个 Sun 提供的 JDK 实现:

“我看到的是,Java SE 不再是一个开放标准,下一次发布将是 JDK 7,而不是 Java 7。这是所有关心 Java 生态环境的人应该关注的问题。”

毕竟,如果 Sun 使 Java SE 不再是一个开放标准,那么 Java EE、Servlets 或者 JMS 呢?是时候呼吁开放标准的回归了!”

一个后续的文章中,Colebourne 借用 JCP 执行委员会的会议记录支持他的观点,声称这次过程的改变与 Sun 和 Apache 在后者争取对 Harmony 项目的 Java 兼容工具包(JCK)授权条款方面的长期分歧有关。

“... 在 2008 年九月份的会议上,有明显的迹象表明(但不是绝对证据)Sun 认为除非 Harmony 项目的争端得到解决否则不能让一个 Java SE 7 JSR 通过。我们也能够注意到 2008 年四月和六月之间 Sun 的态度变化,Java SE 7 平台 JSR 从'尽快'到‘尚无计划’,同时 Sun 更加关注使用 Open JDK 而不是 JSR。”

Colebourne 的观点得到了 Neil Bartlett 的支持。根据传言,Sun 以可能被收购为理由使用 OSGi 而不是 Jigsaw,Neil Bartlett 据此认为一旦 Sun 被收购,Sun 领导的任何不被 JSR 支持的倡议都会被扼杀:

“明年这个时候 Sun 不可能还以现在的形式存在。不论是被 IBM 收购还是被 HP 和 Oracle 瓜分,或者其他的谣传,Sun 支持 Jigsaw 的承诺毫无意义。因为 Jigsaw 与所有潜在收购者的商业需求背道而驰。我确信,如果 IBM 得到了 Java,它会杀死 Jigsaw。Oracle 也是。通过在 JSR 之外构建 Jigsaw 和反对以建立的行业标准,Sun 向客户暴露了可怕的商业风险。”

到目前为止,Apache 投票反对所有 JSR 的策略和与 Sun 的持续争端还没有对 Java 的发展造成任何实质的影响,因为他们从其他 JCP 成员中只能获得有限的支持。这可能是因为其他 JSR 不受相同许可条款的影响。但是 Java SE 7 将会直接受到影响。如果 Colebourne 的猜测是对的,也就是说,Sun 是因为 Apache 的策略而改变 Java 7 的开发方式,那么双方的僵持将会逐渐对 Java 和 JCP 造成巨大的伤害。



查看英文原文:Sun's Disagreement With Apache Overshadows Java 7 Announcement

Java语言 & 开发架构