我可以看到闭包的一些好处，例如它们如何在简化现有库和使一些未来的设计更容易和更高效方面占有一席之地。
但是，提案草案 (http://www.javac.info/consensus-closures-jsr.html) 中提到的关键点之一在第 2.5 节 e 点：
（规范将通过改进语言）
e)使未来的 API 设计能够取代语言设计以扩展 Java 平台。
我很难看到这是怎么回事，当然语言设计就是这样 - 语言本身的设计，并且不能被 API 取代，除非 Java 使用闭包打开各种奇怪的 API 来修改语言（我非常怀疑这会发生。）
任何人都可以对此有所了解，并可能提供一个以前需要更改语言的示例，但是随着闭包的添加，不再需要一个？
API 设计和语言特性在某些方面绝对可以互换。只需看一下 Java 中的 synchronized 关键字之类的东西。它是一个关键字，但如果语言足够不冗长，它也可以作为 API 来实现。注释是另一个例子。使类中的所有方法都具有事务性的 @Stateless 注释的另一种方式也可能是语言关键字。
特别是闭包可以很容易地将“代码块”交给一个方法，然后可以用它做一些事情。
一个粗略的例子，可以为每个做一个：
for_each(myFooList, #(Foo foo) {
String something = foo.getBar() + foo.getKaz();
System.out.println(something);
});
可能不像语言语法直接支持 for each 循环那样 100% 干净，但它让每个人都可以轻松体验类似语言的增强功能。
对于尚未阅读提案草案的任何人，以下是同一文档后面的更多详细信息：
闭包的添加简化了 Java 平台的演变。Sun 的公共错误数据库中的许多现有语言 RFE 可以重新定位为接收闭包的方法的 API 请求。可以通过添加库方法来满足未来对其他语句形式的许多需求。