Java 7 路线图更新：反响强烈 JavaJVMSwingJavaFX应用服务器
程序员文章站
2022-03-13 11:24:53
...
在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。
出席会议的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。