Javaの閉鎖により、API設計が言語設計を置き換えることができますか？

Question

既存のライブラリを簡素化し、将来のデザインをより簡単かつ効率的にするために、閉鎖の利点のいくつかを見ることができます。

ただし、ドラフト提案（http://www.javac.info/consensus-closures-jsr.html）に記載されている重要なポイントの1つは、セクション2.5、ポイントEにあります。

（仕様は言語を改善します）

e） 将来のAPIデザインがJavaプラットフォームを拡張するための言語設計を置き換えることを可能にします。

私はこれがどのようにケースであるかを見るのに苦労しています、確かに言語のデザインはまさにそれです - 言語自体のデザインであり、Javaが言語を変更するためにクロージャーを使用してあらゆる種類の奇妙なAPIを開いていない限り、APIに置き換えることはできません（私は非常に疑いがあります。）

誰もがこれに光を当て、おそらく以前に言語の変更を必要とする何かの例を提供することができますが、閉鎖を追加してももう必要ありませんか？

Answer 1

APIの設計と言語の機能は、ある時点で間違いなく交換可能です。 Javaの同期されたキーワードのようなものを見てください。これはキーワードですが、言語が十分に非偏見である場合、APIとして実装することもできます。注釈も別の例です。クラストランザクションのすべてのメソッドを作成する@Stateless Annotationの逆の方法も、言語キーワードであった可能性があります。

特に閉鎖により、メソッドに「コードブロック」を簡単に渡すことができます。

粗い例、それぞれの場合は、次のことを行うことができます。

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

言語の構文によって直接サポートされている各ループを持っているほどクリーンではないかもしれませんが、誰もが言語のような強化を簡単に経験することができます。

Answer 2

ドラフトの提案を読んでいない人のために、同じ文書の後半のもう少し詳細を以下に示します。

閉鎖の追加により、Javaプラットフォームの進化が簡素化されます。 Sunのパブリックバグデータベースの多くの既存の言語RFEは、APIリクエストとしてリターゲットになることができます 閉鎖を受ける方法. 。代わりに、追加のステートメントフォームの多くの将来のニーズは、ライブラリメソッドを追加することで満たすことができます。