BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース JDK 7が、突然"単純な"クロージャをサポート、しかしリリースは、2010年の終わりに。

JDK 7が、突然"単純な"クロージャをサポート、しかしリリースは、2010年の終わりに。

原文(投稿日:2009/11/19)へのリンク

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が見直された。 restrictedunrestricted な関数の型やクロージャという概念はなくなった。今やすべてのラムダ式は、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 ライブラリを再び組込んで、新しいクロージャのサポートを利用できるかもしれないと考えていました。

ClosuresJDK 7 についてもっと知りたければ、この InfoQ!を見てください。

この記事に星をつける

おすすめ度
スタイル

BT