Stephen访谈：为什么要加入闭包

一年前，Sun的首席工程师Mark Reinhold在Devoxx大会上宣布Java的下一个重要版本Java7将不会包括闭包；而一年后，还是在Devoxx大会上，Reinhold令人意外的宣布，Java7中将引入闭包。是什么原因让SUN作出这个改变呢？在这次访谈中，Bill Venners将采访joda.org的项目主管、FCM闭包提议的合著者Stephen Colebourne，讨论他对于这个重大改变的看法。

Bill Venners：你认为是什么原因使SUN对一年前的宣布作出改变，最终决定在JDK7中加入闭包？
Stephen Colebourne：一年前SUN认为没有充足的时间为JDK7中加入闭包，因为有太多不同的闭包提议，而且没有足够的经验去决定采用那一个。一个因素是JDK7的发布推迟到明年的年末，这样就有了足够的时间。并且Neal Gafter的BGGA实现提供了一些经验，让他们决定哪些是需要的而哪些是可以舍弃的。
从理论的角度，BGGA提议提供了最为完整的闭包实现。我认为Mark Reinhold评估了BGGA提议并且决定舍弃提议中原有的non-local return以及control invocation statement。在去掉了这些之后，BGGA看起来与v0.5的FCM提议非常相似。我建议将0.6a的提议重命名为 CFJ (Closures For Java).

Bill Venners：你认为还有哪些其它的因素影响了这个决定？
Stephen Colebourne：我认为最为关键的原因是fork-join框架改变了人们的看法。Doug Lea已经完成了fork-join框架的工作。其中的并行阵列API及其繁琐，仅仅是针对四种基本类型，就需要80个interface。并且对程序员及其不友好，你需要使用内部类，并且使用正确的泛型；你还得从80个interface中作出正确的选择。而闭包将很大程度上简化这些API并且使用起来更加简单。

FCM (First Class Methods)提议：http://docs.google.com/Doc?id=ddhp95vd_0f7mcns
BGGA闭包提议：http://javac.info/
Stephen Colebourne's Weblog：http://www.jroller.com/scolebourne/entry/closures_in_jdk_7