java中闭包_Java 7中的闭包-语言的新时代开始了吗?

java中闭包

Java had always been an easily readable and understandable language.  Some relatively recent changes in the language seem to be changing this pretty fast, and anyone that had not seen any Java code for the last 5 years will possibly have issues understanding some of the code that is written nowadays.  And one of the new features of Java 7 seems to be adding even more to the confusion.

Java一直是一种易于阅读和理解的语言。 语言的一些相对较新的更改似乎正在快速改变这种情况,并且在过去的五年中没有看到任何Java代码的任何人都可能会在理解当今编写的某些代码方面遇到问题。 Java 7的新功能之一似乎使混乱更加严重。

Java 5:泛型 (Java 5: Generics)

When Sun announced their plans to include the Generics in Java 5, a lot of the developers were not exactly happy, even though they were not a foreign concept for most of the people that had started with other languages before the creation of Java. This change added a lot of complexity to the language.  But they were part of the evolution of Java, so most developers accepted them, and found good usage for them (is there anyone missing the casting or conversion that was needed every time when an object had to be retrieved from a collection?).  But, at the same time, expressions like

当Sun宣布他们计划在Java 5中包含泛型时,即使对于大多数在Java创建之前就开始使用其他语言的人来说,这并不是外国概念,但许多开发人员并不十分满意。 这种变化增加了语言的复杂性。 但是它们是Java演变的一部分,因此大多数开发人员都接受了它们,并为它们找到了很好的用法(是否有任何人每次需要从集合中检索对象时都缺少所需的转换或转换?)。 但是,与此同时,

<T extends Object & Comparable<? super T>> T Collections.max(Collection<? extends T>) { ... }

prove that even if Generics are generally a great idea and can be quite useful, they also open the door for a lot of issues. And that's not even close to the most complicated expressions that can be done. Most of the experienced Java developers can understand this line but that does not make it readable or easy to understand.

证明即使泛型通常是一个好主意并且可以非常有用,它们也为很多问题打开了大门。 而且这甚至与可以完成的最复杂的表达式还差得很远。 大多数有经验的Java开发人员都可以理解这一行,但这并不能使其变得易读或易于理解。

Java 6:平静时期 (Java 6: The calm times )

After the release of Generics, things in Java started to move quite nicely--the new versions started fixing the problematic areas without any major language changing events, and even though the discussions for all types of changes and revisions never stopped, no one expected anything to happen for a while, especially after the official announcement at the Devoxx conference, at the end of 2008, that the closures will not be part of Java 7 (which was expected to be released in early 2010).  This was pushing them for the Java 8 release (if not a later one), and was allowing the language to get through the bigger issues first (the garbage collector, the memory management, the non-modularity of the JDK to mention just a few), before adding another major component.

泛型发布后,Java方面的情况开始发生很好的变化-新版本开始修复有问题的区域,而没有发生任何重大的语言更改事件,即使有关各种类型的更改和修订的讨论从未停止,但没人期望这种情况会持续一段时间,尤其是在2008年底Devoxx会议上正式宣布关闭之后,该关闭将不会成为Java 7的一部分(预计将在2010年初发布)。 这将它们推向Java 8发行版(如果不是更高版本的话),并允许该语言首先解决更大的问题(垃圾收集器,内存管理,JDK的非模块化等) ),然后再添加其他主要组件。

Java 7:闭包又回到了桌子上 (Java 7: Closures are back on the table )

Then came the announcement that the release of JDK 7 is pushed for September 2010, and possibly later.  And just a few months ago came the latest news:  on the same conference as in 2008, but a year later, the closures were officially announced as the newest addition to Java 7.

随后,宣布将JDK 7的发布推迟到2010年9月,甚至以后。 就在几个月前,出现了最新消息:在与2008年相同的会议上,但是一年之后,正式宣布关闭Java 7。

Java had always had partial closures - the anonymous inner classes were very close in meaning to what closures are doing in other languages.  For example, the simple action of adding a listener to a button required a fully implemented inner class:

Java一直都有部分闭包-匿名内部类在意义上与其他语言中的闭包非常接近。 例如,向按钮添加侦听器的简单操作需要完全实现的内部类:

jButton.addActionListener(
   new ActionListener() { 
      public void actionPerformed(ActionEvent e) { 
         doSomething();
      } 
   } 
);
jButton.addActionListener(#(ActionEvent e) doSomething());
{ => void } el = object#action();
{ String => void } el = { Object object => System.out.println(object); };

All the examples above are using the BGGA closures proposal syntax. The second proposal is the FCM one. Technically it is still unclear which one will be the final one even though all indications seem to be pointing to the first one, even if the declared base is the second one (with some parts excluded - you can look at the resources at the bottom of the article for more information).  Both proposals are close--the drafts have a lot of similarities, and some of the bigger differences had already been ruled out as not becoming a part of JDK 7.

上面的所有示例都使用BGGA闭包提议语法。 第二个建议是FCM 。 从技术上讲,尽管所有迹象似乎都指向第一个,但仍不清楚哪个将是最后一个,即使已声明的基准是第二个(排除了某些部分,您也可以查看下面的资源)有关更多信息的文章)。 这两个提案都很接近-草案有很多相似之处,并且已经排除了一些较大的差异,因为它们并未成为JDK 7的一部分。

What will end up in the language is anyone's guess at this point, but I suspect that the codes above will end up working when JDK 7 gets published.  Until then, it is time to sit down, wait and watch the news coming from Oracle.  Sooner or later the specifications will get closed, and we all will need to get used to the new syntax when it shows up with Java 7--as we did with Generics back in Java 5.  And I suspect that I will write more than one article about the closures when the things get a little more clearer.

在这一点上,最终的结果是任何人都在猜测,但是我怀疑以上代码将在JDK 7发布后最终生效。 在此之前,是时候坐下来等Oracle的消息了。 规范迟早都会关闭,并且当Java 7中出现新语法时,我们所有人都需要适应新语法-就像我们在Java 5中对Generics所做的那样。而且我怀疑我会编写不止一个关于闭包的文章,事情会变得更加清晰。

资源资源 (Resources )

If you are interested in the topic (or if this article made you curious), here is a small list of additional reading materials:

如果您对该主题感兴趣(或者如果本文使您感到好奇),那么这里是一小部分其他阅读材料:

Stephen Colebourne's Weblog - and you might want to look closely at the table that he had compiled for the differences between the different proposals 斯蒂芬·科尔本(Stephen Colebourne)的Weblog-您可能需要仔细查看他为不同建议之间的差异而编制的表格

翻译自: https://www.experts-exchange.com/articles/2690/Closures-in-Java-7-does-a-new-era-start-for-the-language.html

java中闭包

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值