私は、既存のライブラリを簡素化し、将来の設計をより簡単かつ効率的にする方法など、クロージャの利点のいくつかを見ることができます。Javaでのクロージャは、API設計を言語設計に置き換えることを可能にしますか？
しかしながら、案に記載さキーポイント（http://www.javac.info/consensus-closures-jsr.html）のセクション2.5にあり、点E：
（仕様は、Javaプラットフォームを拡張するための言語設計を将来のAPI設計に置き換えることができるように、
e）によって言語を改善する。
私はこのことがどういうことか分かりませんが、言語の設計はちょうどそのようなものです。それはJava自体のデザインであり、Javaがあらゆる種類の奇妙なAPI
言語を変更する必要があるものの例を提供することはできますが、クロージャを追加しても不要になることはありますか？ 1？草案の提案を読んでいたことのある人のために
APIの設計と言語の機能は、一部の点で間違いなく互換性があります。 Javaの同期キーワードのようなものを見てください。これはキーワードですが、言語が十分に非冗長であれば、APIとして実装することもできます。アノテーションは別の例です。クラス内のすべてのメソッドをトランザクションにする@Statelessアノテーションのもう一つの方法は、言語キーワードであった可能性もあります。
クローズでは、特に「ブロックコード」をメソッドに渡すことが容易になり、そのコードで何かを行うことができます。直接言語の構文でサポートされている各ループのためになるよう
for_each(myFooList, #(Foo foo) {
String something = foo.getBar() + foo.getKaz();
System.out.println(something);
});
多分100％としてきれいではないが、それは誰もが簡単に体験することができます：
の粗たとえば、それぞれに作ることができます言語に似た拡張機能を備えています。
は、ここに後で同じドキュメント内からもう少し詳細です：
クロージャの追加は、Javaプラットフォームの進化を簡素化します。 Sunのパブリックバグデータベースにある既存の言語RFEの多くは、を受け取るメソッドのAPIリクエストとしてリターゲティングすることができます。ライブラリメソッドを追加することによって、将来の追加のステートメントフォームに対する多くのニーズを満たすことができます。
彼はまた、Rubyのような文法（つまり、あなたの 'for_each'ループでの定型化さえしていない文法）を今のところ議論しているものよりもJavaの古いクロージャーの提案の1つを探しています。 –