Mark Reinhold氏は、Devoxxコンファレンス開催中、JDK 7がクロージャをサポートすることを公表した。この非常に 議論された フィーチャをサポートするために、JDK 7のリリースは、2010年の9月ごろまで延びる。
Java 7での小さな言語変更を目指した Project Coinのチーフエンジニアである、Joseph D. Darcy氏は、Java言語の次のバージョンは、 ある種の “軽量の” クロージャをサポートする、と正式に発表した:
… JDK 7は、クロージャを持ちます、BGGA版のクロージャより小さなものを開発します。リリースも2010年も9月ごろに延びます。
Devoxxコンファレンスに参加したAlex Mille氏は、 これまでコミュニティは、3つの異なった提案をしてきましたが、サンはクロージャに乗り気でなかった、と話しています:
実際どうすべきかは、私には言えません。長年、サンは、クロージャに関して同意が得られていない、と言ってきました。そして、プロトタイプもある3つの 提案があるにもかかわらず、JSRの作成すなわち、この件の専門グループの作成を延ばしてきました。
Devoxxでの発表の後に、 3つのクロージャの提案 の1つ(BGGA, Bracha, Gafter, Goslingと von der Ahéの4氏のイニシャルから名付けた)の共同起案者である、Neal Gafter氏は、 “単純化された提案”をリリースした:
この修正版における変更点は
- control invocation syntax は別仕様とする。
- 用語 クロージャ リテラルを ラムダ式に変更。
- Clangから緩く拝借して、ラムダ式のシンタックスを全面的に見直した。今や、ラムダ式には2つの形式があり、 expression lambda は、制御された式を持ち、一方、 statement lambdaは、制御されたステートメントを持つ。
- 用語 クロージャ・オブジェクト は、 関数オブジェクトに変更。
- 用語 クロージャ・コンバージョン は、 ラムダ・コンバージョンに変更になり、control invocation syntaxによる別の ブロック・コンバージョンもある。
- returnステートメントに新たなセマンティクスを追加した。それは、今やstatement lambda（ステートメント・ラムダ）から戻るために使うことができる。
- Scala のようにjava.lang.Unreachable が java.lang.Nothing と名称変更された。
- 型名としてのnullは、サポートされなくなった。これまでのバージョンでは、なにもスローできない時に、プレースホルダとして、例外の型にnullを使った。今やタイプ
Nothingがその目的を果たす。- restrictedが見直された。 restricted と unrestricted な関数の型やクロージャという概念はなくなった。今やすべてのラムダ式は、restrictedである。これまでの仕様のunrestrictedクロージャと同等なものは、 control invocation syntaxを使って、メソッドに渡せばよい。
- メソッド・参照 のサポートを追加: 新たに導入されたトークン
#を使って、関数としてメソッドへの参照を扱うのをサポートする。シンタックスは、 Javadocにおけるクロス・リファレンス と FCM 提案 から借りた。
JDK 7の突然の計画変更で、Fabrizio Giudici氏のような人々は、 決定プロセスについて懐疑的になった:
それがいいとか、悪いとか議論したくはありません (
知っての通り、悪いと思いますが提案は、BGGAでもCICEでもなく、新しいものだと理解したので、判定を保留します）。Project Coin（有名な The Final Five (Or So)）にJava 7の最終仕様が載った、数週間後に、誰かが突然考えを変えたのに、ぎょっとしただけです。これは、一体どんな決定プロセスなんでしょう？
あー、わかりました。 コインを投げたのですね。今、プロジェクト名前がどこから来たのかがわかりましたよ。Java 7がこれまでのJavaのリリースで最も混乱したものになるのでは、と恐れています。早産で、Java 7を葬りたいなら大変いい考えですが（すでに他にたくさんのエントロピ源がありませんでしたっけ、オラクルの買収とかJigsawとOSGiの論争とか）。
同様に、Geertjan Wielenga氏は、 クロージャが含まれるのは、全く予想外の展開だった、と考えている:
素晴らしいニュースです。そして、どのようなプロセスで、結局この回答をもたらすことになったのかついて、あまり多すぎる質問を誰もしなければ、おそらく最高のニュースです。最初、たくさんの提案がありましたが、どれもぱっとしない反応でした。それから突然、青天の霹靂のように、 "単純なクロージャ"を持つことになった（今提案されているものがどれも "複雑なクロージャ"と呼ばれているのでしょうか。第一、クロージャの目的はそもそも単純さではないのでしょうか？）わかりました。非ローカルなリターンがない、コントロール・ステートメントがない、finalでない変数へのアクセスが無い、という意味で、クロージャは、単純になる、ということですね。でも、そのような決定はどうやってされたのでしょう？
Cay Horstmann氏は、FCM 提案 に大変似ている、この新しいBGGA提案でいくつかのユースケースを示した :
サンが正確に何をしようとしているのか、本当にはわかりません。私は、簡単にBGGA 0.6a版の提案を分析しましたが、思うに今日のBGGAのものと変わりません。FCMと似ているところがたくさんあるのは、否定できません。非ローカルのリターンがありません。ラムダ式に#が使える。ミューテイトした変数を捉える時、@Sharedで変数を注釈する必要がある。下のように書く時、おそらく2度考えるでしょう。
foreach(@Shared String v : values) funcs.add( #() => v);
Alex Miller氏は、JDKの計画が延びたので、Javaオブジェクトの配列のマッピング、フィルタリング、削減用の関数スタイルのAPIを提供する ParallelArrayライブラリのような他のフィーチャをこのリリースに入れることができるかもしれない と言う:
私は、QConでBob Lee氏とちょっと話したのですが、彼は、JDK 7の日程が延びたので ParallelArray ライブラリを再び組込んで、新しいクロージャのサポートを利用できるかもしれないと考えていました。