Java 7 路线图更新:反响强烈

  • Dio Synodinos
  • 崔康

2009 年 1 月 5 日

话题:Java语言 & 开发架构

在 Devoxx 大会上,Java SE 首席工程师 Mark Reinhol,做了一个关于 Java 7(2010 年初发布)最新发展方向的演讲。虽然,Mark 称这次演讲的内容只是暂时的计划、不具约束力,但是仍然在社区中引起了很多反响,特别是针对闭 包特性(Closures)的遗漏。

出席会议的 Hamlet D'Arcy 提供了一个Mark 演讲中有关 Java 7 特性的总结。其中一些比较重要的变化包括:

模块化——294 和 Jigsaw 项目

292——JVM 对动态语言的支持

JSR 203——更多新的 I/O API 已基本完成,包括真正异步的 I/O(不仅仅是非阻塞 I/O)和一个真正的文件系统 API。

JSR TBD:小的语言变化(见下)

安全重抛出——允许一个广泛的 catch 语句,编译器可以更加智能的基于 try 语句块中抛出的异常管理重新抛出。(我以前没有见过,不过看起来不错)

Nulll 解引用(dereference)表达式——Null 通过'?'语法检查,类似于 Groovy... 使开发人员避免一连串 null 检查。

更好的类型推断(type inference)——与泛型实例化有关,但目前还不清楚这种推断会达到什么程度(我觉得越多越好)。

多捕捉(Multi-catch)——(是的!)允许在 catch 语句中用逗号分割一系列异常类型。

Joe Darcy 正在领导 Open JDK 开发,他的博客地址是 http://blogs.sun.com/darcy

JSR 296——Swing 应用框架——仍然需要更简化以方便 Swing 应用开发。

6u10 特性的向前兼容(Java Kernal、QUickstarter、新 Plug-in 等)。

他同时提到了曾经考虑过但可能不会引入到 Java 7 的特性:

闭包——围绕提议没有形成一致意见

具体化泛型(Reified generics)

第一类属性(1st class properties)

操作符重载

BigDecimal 语法

JSR 295——Bean 绑定

Java.net 开展了一次有关“哪些 Java 7 未采纳的特性是你最感兴趣的”的调查,其中闭包明显处于其他特性之前

闭包                                           47.4% (734 Votes)

具体化泛型                               17.2% (266 Votes)

第一类属性                               10.4% (162 Votes)

操作符重载                                4.3% (67 Votes)

BigDecimal 语法                       3.4% (54 Votes)

JSR-295 Bean 绑定                  7.3% (113 Votes)

我对任何特性都不感兴趣         9.7% (150 Votes)

Ricky Clarkson 认为没有闭包 Java 将灭亡

果然被证实了。虽然 James Gosling 想要闭包,虽然已经有了 3 个闭包原型编译器,虽然其他 JVM 语言支持闭包,Java 7 还是没有闭包。

Martin Kneissl 也认为Java 7 中没有闭包是个坏消息

应该增加闭包而不是 Java 5 中的“for”循环新形式。在 Java 6 中就应该有闭包。现在似乎 Java 7 中也不会有了。

闭包并不难以理解。至少当你把它们与 Java 中的匿名内部类作比较时是这样的。有的人不赞同。他们觉得总有一些愚蠢的程序员,所以应该限制语言以防止他们引起太多破坏,我不认同这个理由。这是不可能的。不称职的程序员在任何语言中都会搬起石头砸自己的脚

幸运的是,JVM 上还有其他语言可以使用 Java 的优点:库、可移植性和工具(某种程度上)。

Dustin Marx 在关于 Java 7 中最期待的特性的帖子中对闭包有一些矛盾的看法

就在我写这篇帖子的时候,已经有 160 票投完(不过很快就会出现新的投票),其中 Java SE 7 中最期待的落选特性是闭包。目前,闭包特性已经得到了总票数的几乎一半。从某种意义上说,这并不奇怪。闭包似乎主宰了Java SE 7的讨论直到被宣布不会在Java SE 7中引入。但是讨论是围绕着闭包的概念和如何实现闭包进行的争论。虽然闭包是 Java SE 7 最期待的落选特性之一,但是我个人对此非常矛盾。我有时会偶然的在工作中意识到闭包是多么有用,但是多数情况下没有它我也可以应付。也就是说,我不介意它被引入,但是当我听到没有被包含在 Java SE 7 中时这并没有困扰我。但是,如果我们相信目前的投票结果,那么接近一半的 Java 开发人员最想要这个特性。这与 Java.net 有关开发人员最想要 Java SE 7 引入闭包的问卷调查是一致的。

Osvaldo Doederlein对新特性感到兴奋,不过仍然很期望闭包

Java 7 是多年基础设施智能化的最好版本:294/Jigsaw,并发类加载——我认为这会提高大应用程序的启动时间,特别是类似于 JavaEE 服务器和 IDE 等基于微内核的应用,XRender——将最终使 Java 成为 Linux 桌面应用的一等公民,G1,全 64 位支持(将在 6u12 中首次亮相,获取 beta 版),ForkJoin。

这么多的好特性,我几乎都快忘了失去闭包的悲伤了。我猜是时候转移到 Scala、JavaFX 或者其他现代 JVM 语言上了(只要不是类似于 Ruby 或者 Python 的动态类型语言)。我认为从现在开始五年,如果我编写某种低层次的运行时,我会只写“标准”Java 代码。多亏社区的保护,Java 语言 正在慢慢转为一种遗产和低层次的角色。

另一方面,Matt Grommes关注于 BigDecimal 语法

我致力于一个金融系统有一年多时间了,BigDecimal 语法简直太痛苦了。我真的非常不满意。

Stephen Colebourne 向 Devoxx 和 JavaEdge 的与会者展示了JDK7 语言的 10 种可能变化,并请他们投票:

绝对的胜者是——null 处理。Null 处理获得了 50 张最优先支持票,是排在第二位的字符串切换(string switch)特性票数的两倍,几乎是全部最优先支持票数的三分之一。而且,几乎有三分之二的与会者把它放在了前四位优先支持的特性里。

其他受欢迎的特性包括字符串切换、异常的多捕捉、对 Map 的增强型 for-each 循环(能够删除或者查找索引)和 ARM 风格的资源管理。

不受欢迎的特性(特别认为是糟糕建议的)是通过 [] 访问 List/Map 和字符串插值(字符串中的 ${variable} )。

泛型推断和多行字符串处于相对较低优先级但与会者不是特别反感。

值得一提的是,在 Devoxx 上对闭包特性的投票结果是 50:50。

您可以从 infoQ 中找到下一代 Java SE 平台的更多信息

查看英文原文:Java 7 Roadmap Updated: Reactions

Java语言 & 开发架构