Java中的关闭将使API设计能够替换语言设计？

Question

我可以看到关闭的一些好处，例如他们如何在简化现有库并使未来的设计更加轻松，更高效方面拥有自己的位置。

但是，提案草案中提到的一个要点之一（http://www.javac.info/consensus-closures-jsr.html）在第2.5节，点E：

（规范将通过

e） 使未来的API设计替换语言设计以扩展Java平台。

我正在努力了解这种情况，语言设计肯定就是这样 - 语言本身的设计，除非Java使用封闭方式打开各种怪异的API，否则无法用API替换。 （我高度怀疑会发生。）

谁能为此提供一些启示，并可能提供一个以前需要语言更改的东西，但是，随着封闭的添加，不再需要一个语言？

Answer 1

API设计和语言功能在某些时候绝对可以互换。只需看一下Java中的同步关键字即可。这是一个关键字，但是如果语言足够非词语，则可以作为API实现。注释是另一个示例。另一种方式围绕@Stateless注释，该注释使类交易中的所有方法都可能是语言关键字。

尤其是关闭使得可以轻松地将“代码块”交给方法，然后可以对此做些事情。

一个粗糙的例子，每个人都可以做：

for_each(myFooList, #(Foo foo) { 
   String something = foo.getBar() + foo.getKaz();
   System.out.println(something);
});

也许不是100％干净，而是将每个循环直接由语言语法直接支持，但它使每个人都可以轻松地体验类似语言的增强功能。

Answer 2

对于任何尚未阅读提案草案的人，以后的同一文件中有更多细节：

闭合的添加简化了Java平台的演变。 Sum的公共错误数据库中的许多现有语言RFE可以根据API的要求进行重新定位 接收关闭的方法. 。可以通过添加库方法来满足其他声明表格的未来需求。