|
2#
楼主 |
发表于 21.9.2011 10:44:44
|
只看该作者
以下是社区中的部分反应:
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则对闭包有一些矛盾的看法
就在我写这篇帖子的时候,已经有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语法简直太痛苦了。我真的非常不满意。
Devoxx和JavaEdge的与会者对JDK7语言的可能变化进行投票
绝对的胜者是——null处理。Null处理获得了50张最优先支持票,是排在第二位的字符串切换(string switch)特性票数的两倍,几乎是全部最优先支持票数的三分之一。而且,几乎有三分之二的与会者把它放在了前四位优先支持的特性里。
其他受欢迎的特性包括字符串切换、异常的多捕捉、对Map的增强型for-each循环(能够删除或者查找索引)和ARM风格的资源管理。
不受欢迎的特性(特别认为是糟糕建议的)是通过[]访问List/Map和字符串插值(字符串中的${variable} )。
泛型推断和多行字符串处于相对较低优先级但与会者不是特别反感。
值得一提的是,在Devoxx上对闭包特性的投票结果是50:50。
|
|