では、Java 7 は最終的にクロージャを取得するのでしょうか? 最新のニュースは何ですか?
1253 次
6 に答える
5
はい、Java 7 のリリース計画には閉鎖が含まれていました (そして、リリースが冬から秋 (2010 年 9 月に予定) に延期された最大の理由でした)。
最新のニュースはProject Lambdaでご覧いただけます。また、最新の仕様草案を読むことにも興味があるかもしれません。
于 2010-03-27T12:37:42.403 に答える
3
現時点では、閉鎖の状態に関する公式声明はありません。
これがどのように機能し、どのように見えるかの読みやすい例を次に示します。
何が起こっているのかを知りたい場合は、OpenJDK メーリング リストを参照してください。
概要
コードといくつかのテストがすでにいくつかのソースコードブランチにコミットされており、それをテストするための少なくとも途中で動作するインフラストラクチャがあるため、基本的にはいくつかの希望があります。
Maurizio Cimadamoreからの変更メッセージは次のとおりです。
初期ラムダプッシュ; 現在のプロトタイプは、次の機能をサポートしています。
- 関数型の構文 (オプションで -XDallowFunctionTypes で有効化)
- 関数型のサブタイプ
- タイプ 1 および 2 のラムダ式の完全サポート
- ラムダでのスローされた型/戻り値の型の推論
- v0.1.5 ドラフトで指定されたルールを使用したラムダ変換
- 「this」への参照をサポート (明示的および暗黙的の両方)
- メソッド ハンドルを使用した変換
変更された langtools リポジトリのスクリプト ビルドは、SAM 変換中に使用されるヘルパー クラスを含む javacrt.jar という追加の jar ファイルを生成するようになりました。ビルド後、生成されたスクリプト javac/java は、ラムダ式を含むコードをコンパイルして実行できるように、必要な依存関係を自動的に設定します。
しかし、これは進行中の作業であり、現時点ではかなりバグがあります。たとえば、コンパイラは有効な式でクラッシュしたり、正しいクロージャ構文コードをコンパイルしたり、不正なバイト コードを生成したりすることがあります。
否定的な側面として、ニール・ガフターの声明がいくつかあります。
0.15 のドラフトからほぼ 3 か月が経過し、openjdk7 機能が完成する前の TL (Tools and Languages) の最終的な統合まで 2 週間も経っていません。仕様と実装に関して進展がありましたら、共有していただければ幸いです。そうでない場合は、おそらく私たちがお手伝いできます。Oracle がこの機能が JDK7 にとってもはや重要ではないと判断した場合は、それも知っておくとよいでしょう。何が起こっても、沈黙は間違ったメッセージを送ります。
ニール・ガフターとジョナサン・ギボンズの対談:
これを見てよかった、マウリツィオ！残念ながら、jdk7 に含めるには 1 週間遅すぎ、間違ったリポジトリに到着しました。
どのテストも、関数型の変数が SAM 型に変換されていることを示していないことに気付きました。そこにはどのような計画がありますか？ Jonathan Gibbons の回答: jdk7 の公開された機能リストと jdk7 の公開されたスケジュールは矛盾しているように見えるのに、スケジュールが正しいといつも仮定するのはなぜですか? ニール・ガフターの回答: 機能セットは、スケジュールの完成状況に基づいて調整されるという趣旨の議論が繰り返されたことを思い出したためです。
一部の人々は、全体がもはや理にかなっているかどうか疑問に思い、別の言語に移行することを提案しています:
どうして Scala に移行しないのかと疑問に思う人もいるでしょう。ラムダに関する機能の一貫した組み合わせを構築するために Java に追加する必要があるものは他にもたくさんあります。そして今、これらの遅延は、ParallelArray のユーザーだけでなく、きちんとリファクタリングされたテスト可能なソフトウェアを Java で構築したいと考えているすべての人に影響を与えています。
Javaで宣言サイトの差異を追加することを誰も提案していないようです=>
FunctionN<T, ...>インターフェイスが本来の方法でサブタイプ化されないことを意味します。また、プリミティブの特殊化もありません。(Scala の @specialized は、おもちゃのクラスを除くすべてのクラスで壊れていますが、少なくとも正しい方向に進んでいます)Scala のクロージャーの削除 (HOF もインライン化できる場合) のように、オブジェクトがクロージャーであり、したがって削除できるという JVM レベルの認識はありません。ループ内であっても、インラインキャッシュされていてメガモーフィックではないと思われる場合でも、ポリモーフィックな呼び出しサイト。私が見た結果は、Scala で @inline できるもの以外のクロージャーの形式で実装された場合、「整数の配列の合計」のようなおもちゃのマイクロベンチマークで約 2 倍の速度低下です。(そして Scala でも、ほとんどの HOF は仮想であるため、インライン化することはできません。) 私は、すべての for ループでクロージャの使用を/奨励する/言語で使用可能なインライン化を見たいと思っています。
結論
これは進行中の問題全体の簡単な説明にすぎず、引用とステートメントはまったく網羅的ではありません。現時点では、人々はまだ「Java で本当にクロージャを実行できるのか? もしそうなら、どのように実行すべきで、どのように見えるのか?」という状態にあります。
「わかりました。週末に Java にクロージャを追加するだけです」という単純なものはありません。配列としての varargs、型消去などのいくつかの設計ミスの相互作用により、うまくいかない場合があります。これらの小さな問題をすべて見つけて、修正可能かどうかを判断するのは非常に困難です。
最後に、いくつかの驚きがあるかもしれません。その驚きが何であるかはわかりませんが、次のいずれかになると思います。
- クロージャは Java 7 または
- Java 7 のクロージャは、Java 5 の Generics と同じになります (バグの多い、複雑なもので、動作するように見えますが、もう少し進めるとすぐにバラバラになります)
個人的な意見
私はずっと前にScalaに切り替えました。Oracle が JVM に対して愚かなことをしない限り、私はもう気にしません。Java 言語の進化の過程で、下位互換性が原因の 1 つとして誤りがありました。これにより、人々が新たに変更を加えようとするたびに、追加の負担が生じました。
基本的に: Java は動作しますが、言語の進化はもうありません。人々が変更を加えるたびに、次の変更を行うためのコストが増加し、将来の変更がますます起こりにくくなります。プロジェクトCoinのようないくつかの小さな構文の改善を除いて、Java 7の後にJava言語に変更があるとは思いません。
于 2010-06-19T21:01:39.803 に答える
1
于 2010-03-27T12:07:51.350 に答える
0
私は今、リリース会議に参加しており、講演者は Java 8 の閉鎖が近づいていると言っています。
于 2011-07-13T03:51:07.993 に答える
0
lambda-devメーリングリストでは、構文と透明性に関連する議論が非常に多く（特に、特定の構文でカリー化関数を読むのがいかに難しいかに焦点を当てているようです）、いくつかのドラフト提案がありましたSun からのイテレーションですが、しばらくの間、そのリストにあるものはあまり見られませんでした。
于 2010-03-27T14:46:35.957 に答える
0
最新のニュースは、2009 年 11 月下旬の時点でもまだ Java 7 で何らかの形で閉鎖が行われるということです。これがリリースの大幅な遅れの主な理由として挙げられているため、再びドロップする可能性はほとんどないようです.
于 2010-03-27T12:10:48.147 に答える