BT

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

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース JDK7 のフィーチャが遅れる

JDK7 のフィーチャが遅れる

原文(投稿日:2010/09/10)へのリンク

JDK7を再考する 、というタイトルの投稿で(そして jdk7-devにも、クロスポストされている)、 Mark Reinhold氏は、リリースを遅くするのではなく、早めるために、以前JDK7に計画されていた内のあるものは、JDK8まで延ばす、という提案した。この提案が、これはいい考えなのか悪い考えなのかについて、様々な議論を巻き起こした。

以前発表された予定表(とにかく、最初から守れそうなものではなかった)がずれる原因となったJDKの遅れを受け入れているので、現在の議論は、現在サポートできているもので、その前にリリースすべきか、すべてが揃うまで待つべきかに、集中している。氏が提案するのは:

この「 Plan B」の見積りですが、2011年半ばに、削られたJDK7を、2012年の後半にJDK8をリリースできる見込みです。

要約すると:

  • Plan A: JDK 7 ( 現在の予定通り)2012年半ば
  • Plan B: JDK 7 ( ラムダ式, Jigsawを除き、Coin の一部)2011年半ば
  • Plan B: JDK 8 ( ラムダ式, Jigsaw、Coinの残り、更にプラス)2012年の後半

皮肉にも、氏のブログのタイトルは、「一刻の猶予もない!」であるが、投稿に寄せられたいくつものコメントが言うように、リリースが全く無いより、早く、頻繁にリリースがあったほうがよい。Plan Bのフィーチャセットには、非常に望まれるものがいくつかある(そして、あまり期待していないものも)が、 Project CoinのPlan Bの部分は、Java言語にとって有益であることは、疑う余地がない。Joseph D. Darcy 氏によって明らかにされた 、これらには以下のものを含む:

Plan Bは、また jsr166y クラス (ForkJoin, TransferQueue, Phaser)を含む。更に別のJVMの改善が、JVMレベルであり、JSR292invokedynamicのサポート)もそのうちである。これは、静的に型づけされる言語であるJavaでは,ほとんど利用されないように思われるが、Method.invoke()が使われる際(例えば、RMIや他のエンタープライズ サーバ アプリケーションで)には、最適化に使うことができる。もしこれも、MethodHandle リテラルに対する言語サポートを含んでいるのなら、適切に名前のついたメッセージを見つけるのに、リフレクションを使う必要がなくなり、Javaクラス内でメソッドを使うのが,ずっと簡単になる。( MethodHandle リテラルは、見えないところで invokedynamicを使うが、JLSに変更が必要である;なのでPlan Bでは、invokedynamicのVM 命令とMethodHandle クラスは、含まれるが、リテラルのサポートは,無いだろう)。

JVM上に代替言語を実装している人たちは、提案された予定変更に興奮している。invokedynamic が使えるのが、2012年まで遅れるより,早まるからである。(いずれにしても、ラムダ式などが2012年より早くなることはない。)JVM上でJRubyとMirahの両方を開発している Charles Nutter 氏は、その変更に冷静である:

メソッド ハンドルは、恐らく、私の開発にとって、JDK7の中で最も重要な変更です。単一メソッドのクラスを生成する際のオーバヘッド無しに(基本的に、*すべての*現在の」JVM言語は、一箇所か、他の場所でそうすることを強制されます)、関数や関数ポインタを表現したいと思う*すべての*JVM言語にとって、 メソッド ハンドルは、確かに重要な部分になります。しかし、それを長い間リリースできないなら、JRubyのような言語を実装するには、泥んこの中をとぼとぼ歩き続けるしかない、ということです。PermGenスペースが爆発しないように、いつも鋭いコードを生成する戦略を作りながらやるわけです(あるいは、単に余りにたくさんメモリを食わないようにします)。メソッド ハンドルがリリースに入るのが,早ければ早いほど、いいのですが。

なので、 Jigsaw, Lambda, と Coin を喜んで諦めましょうか?Jigsaw と Coin は,恐らくね。これらは、確かにリリースされません。ラムダ式に関しては,本当の関数型と、メソッド ハンドルと invokedynamicとの統合を短期間で「ちゃんと」できないなら、ちゃんとできるまで遅らせるべきです。そう言うのは、つらいですが、JVM上で、クロージャができる言語が他にあります。私が開発している JRuby や Mirah もそうです(ところで、Mirah は、*いかなる*ランタイム ライブラリ すなわち JVMのサポート無しに、 クロージャともっと多くを提供します)、そして、我々 JVM 「システム プログラマ」にとって、匿名インナークラスは、なお「非常にいいもの」です(JRuby のコードベースを見てください、我々は、それらを物凄く使っています)。

ああ、Scalaを得意げに話す皆さん、Plan Bから抜けてしまうフィーチャをScalaは,どうやって解決しているのか,どうか、私に説明願いたい。ええ、Scalaには、クロージャがありますが、他の言語や通常のJava コードとは、一般に相互操作できません(設計にかなりの制限をしなければ)、そのために、Scala 開発者以外には、クロージャは,役に立ちません。Jigsawのゴールに取り組むものは,皆無です。そして、Scalaでは提供している、Coinのほとんどのものは、(私が思うに)既にリリース レベルにあります。Scala は、JVMの共通語として、Java の代替では、ありませんし、これからも、そうはならないでしょう。

他の人達は、もっと早く、そしてリリース回数が、もっと頻繁にされるべきだ,と考えている。Java 6は、長い間使われているが、バージョン付けスキーマが、その間のVM中の重要な変更を隠している。 Osvaldo Pinali Doederlein 氏は、以下のように 書いている:

もちろん,理由は、JDK 6です。私は、常に「 6uNの後の」リリースを追いかけていますが、 Sun/Oracleは、いつも隠し続けています。自分たちのTCKをちゃんと通しながら、できる限り多くの改善を施しているわけです。私は、6u23の最初のビルドを既にテストしましたが、これは(たくさんのSwingの修正に加えて)たくさんのVMアップデートを施していて、今や開発最先端の HotSpot 19(現在のところ、JDK7からの最新版)になっています。この中には、有名なJDK7 のフィーチャである最新のG1 コレクタ、JSR-292の完全なVMサポート、そして64Gb ヒープでの CompressedOopsのような他の項目、CMSの修正、たくさんの小さなVM/ランタイムの修正と改善が含まれています。

バージョン ナンバーは、幾分任意なものです。Sunは、 J2SEJavaSEのバージョン スキーマを何回か変更しています。いつも世界の半数の人は、新しいスキーマを嫌います。ある人達は、6u10は、6.1と呼ばれるべきだ,と考えています。この場合、 6u14->6.2, 6u18->6.3, 6u21->6.4 そして 6u23->6.5 のようにバージョン番号を変えることになるでしょう。多分このほうがいいかもしれません:「やあー、JDK7が遅れる、最低だよ...しかし少なくとも6.5は、あるよ!」

遅れることの別の利点は、慌ててやるよりも物事がちゃんとやられることである。 Lambdaプロジェクトには、競合するゴールがあった。コア Javaライブラリ(例えば:ラムダ式を利用して、どうやって短い時間で、Collectionクラスを修正するのか)は、短い期間では、問題を起こすことになるだろう。Lambdaプロジェクトにもっと時間を与えれば、JDK7を止めること無しに、これらのことがJDK8と調和されるだろう。そればかりでなく、最新の提案では、完全にJavaでの関数型を排除している(以前,InfoQに載った)。もっと時間ができたことを考慮して、決定を再考する 要求がこれまであった。しかし、第一になぜそれらが除かれたかの理由が、はっきりしないので(型システムの問題なのか、時間が足りないのか)、それらが再び蘇るのかどうかも、はっきりしない。

JDKのモジュール システム化を狙った Jigsawについても同じことが言える。OSGiが、これまで長い間、Javaにおけるモジュール システムの標準であるのに,JigsawがJava言語ライブラリを分割する方法として、車輪の再発明をしようとしている。 Qwyltがこれら2つを統一しようとしているが、他のところで書かれているように、JVMとJava ライブラリは、本当に2つの違う目的を実行するものである。JVMをJava ライブラリから分離するPlan C は、誰にとっても、大きな利益をもたらすものである。そうすれば、ライブラリ( IO, NIO, NNIO, NNNIOのような)は、それぞれのスピードで進化でき、今のように、JVM + ライブラリの組合せの特別なリリースに依存することがないようになる。

Peter Kriens 氏が書いている:

Java プラットフォームが大きければ、大きいほど良くなる、という誤解によって、Java は、徐々に壊されている。しかし、より大きくなるということは、より内部的な依存性が増すことを意味し、このような依存関係は、すぐにプラットフォームを複雑にするものである。ロープを持てば持つほど、絡み合いやすくなるのです。繰り返しスケジュールがズレるのが,その徴候の一つです。

モジュール化は、我々がケーキを持ち,食べることができる唯一のメカニズムです。もしJava がコアJava プラットフォームからできていたら、JSRの実装を別のモジュールとして、簡単に含むことができたでしょう。私は、決してSwing を使いません、じゃあ、なぜ私のプラットフォームにそれが入っているのですか?そして,もしそれを私が使うなら、別バージョンのものが必要です。JSRをモジュール化するのは、小さなアプリケーションのライフを恐らく,複雑にするでしょう。しかし、本格的なアプリケーションにとって、外部依存性を処理することは、すでに複雑なライフの一部になっています。複雑になる理由は、驚くことにJava は、これらの依存性を扱うことを全くサポートしないためです。

我々に必要なのは、最小限で、真のモジュール性理解しているコア プラットフォームです。すべてのjavax パッケージを含むのではなく、この最小限のJava は、よく定義されたコアパッケージ、と私のデスクトップマシンとサーバにライブラリやアプリケーションを追加するのが、簡単にできる(リモートの)レポジトリから、モジュールを適切に処理できる、メカニズムだけを持っているべきです。Perl は,それができますし、Ruby もできます。Python もできます。なぜJava は、同じことをするのにそんなに大変なのでしょうか?

我々は、技術を持ってます、必要な全てのパーツを持ってます。Oracle、どうか、この遅延が機会を与えてください。我々は、Java をまたアジャイルにすることができるか?

Oracle がJDK7 の以前に計画していたフィーチャのいくつかを、遅らせることを考えている、という短い発表で、彼らは、問題をPR用のクーデタに変えた。「早くリリース、頻繁にリリース」のアプローチを勇気づける多くのコメントが、Oracle がjavaOne で公式に遅れを発表し、そして、コミュニティが彼らに味方していることを言うよう、Oracle を促している。(もしOracle が遅れを Lambda-Devリストだけに、発表したら、遥かに大きなネガティブな反応と、より少ないポジティブな反応を得ることになったろう。)そうすることが、Java プラットフォームにとって、まだリリースレベルにないライブラリ(ラムダ式)を熟成し、必要かどうかを考える(Jigsaw) 時間ができる、という希望を与えることになる。一つ確かなのは;問題をオープンにすることによって、Oracle は、遂にコミュニティの意見の重要さを理解した、ということである。

この記事に星をつける

おすすめ度
スタイル

BT