Oracle が JDK 8 に向けて提案を募集

作者 Charles Humble , 翻訳者 吉田 英人 投稿日 2011年4月11日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

Open JDK ,

Java SE ,

Java ,

言語 ,

プラットフォーム ,

プログラミング

共有 |

原文(投稿日：2011/04/06)へのリンク

Java 7 のフィーチャーコンプリート(Feature Complete) を受けて Oracle は，関心の先を JDK 8 に向け始めた。Java プラットフォームグループのチーフアーキテクトである Mark Reinhold 氏が Java コミュニティからの 提案を求めている。

大仕事 (big-ticket) になりそうな項目がいくつかあることは，すでに分かっています。それでもまだ大小を問わず，他の機能を受け入れられる余地はあるでしょう。ですから今こそ，JDK 8 以降に向けた新機能の提案や計画を収集整理し，レビューし，優先付けするための，シンプルなプロセスを定義すべき時なのです。

そのプロセスは "メカニズムが簡素" で "できるだけ軽量" であるとともに，"意思決定に透明性を持ち，すべてのコミッタに対して開かれた" ものでなければならない，と Reinhold 氏は言う。提案は現在，構造化テキストファイルの形式で Mercurial レポジトリに収集されている。

氏の言う"大仕事"項目とはおもに，JDK 7 で対応するには困難過ぎる，あるいは異論が多すぎる，と判明していた項目のことだ。その中心となるのはおそらく Java プラットフォーム・モジュールシステム，ラムダ (あるいはクロージャないし匿名メソッドとして知られている) の追加，の２項目だろう。

モジュールシステムの提供は JDK 7 の主目標のひとつだったが，Sun がすでに存在していた OSGi 技術ではなく，自社のソリューションである Jigsaw を選択した時点で，大きな論争になることは目に見えていた。この選択について，Sun 自身が挙げている理由は２つある。ひとつはパッケージされたアプリケーションを，OSGi の場合よりもプラットフォームに強く結び付いたものにしたい，と Sun が望んでいたことだ。そこには Java がサポートするプラットフォーム上において，デスクトップ Java アプリケーションが一級市民 (first class citizen) であることをよりアピールする，という同社の意図があった。もうひとつは，両者の依存モデルが違うことだ。Sun にはパッケージを別々のモジュールに分割して，それらを実行時に同じクラスローダでロードすることを可能にする必要があった – 例えば java.util のようなパッケージを，複数のモジュールに分割する (あるいはメモリに制限のあるシステム用の実装を別途用意する) ためだ。これをサポートするために Jigsaw では，再帰的なローカル依存性，という概念を持っている。これによって，もし ‘Swing’ モジュールが ‘AWT’ モジュールにローカル依存性を持ち，‘AWT’ が ‘base’ モジュールにローカル依存性を持つならば，ランタイム時には Swing，AWT，base の３つが同じクラスローダで処理されるようになる。OSGi にもフラグメントという形で同様なコンセプトがあるが，自身で依存性を処理できないという点において，これほどの柔軟性を持ちあわせてはいない。OSGi にこのような追加要件のサポートを加える，という方法も当然考えられるが，どちらのアプローチを採用するにせよ，Oracle としては OSGi との互換性を持ったアプローチを目標とすることになりそうだ。Java 8 JSR の説明によれば，

Java プラットフォームモジュールシステムの採用する方法が OSGi との相互運用性をどの程度持つべきか，あるいは OSGi に対応するべきか，という点は，JSR の専門家グループと Java SE 8 専門家グループとの間で協議決定される議題になるでしょう。

Java 言語にラムダ式を追加するプランに対しては，さまざまな提案がなされてきた (BGGA 案，CICE 案，FCM 案，C3S 案) が，どのアプローチを採用すべきか，という明確な合意には至っていない。Project Lambda と JSR 335 は，今回も同じ問題に直面することになりそうだ。この議論の中で，"SAM 変換 (SAM conversion)" サポートを追加して，SAM (single-abstract-method) インターフェースあるいはクラスの必要な場所でのラムダ式の使用を可能にすることにより，既存ライブラリの前方互換性 (forward compatibility) を実現する，という提案がある。また JSR でも，Java 言語のインターフェースのセマンティクスを拡張して，仮想拡張メソッド(virtual extension method) をサポートすることを提案している。これは，インターフェースの実装クラスがある拡張メソッドの実装を持っていない場合に，そのメソッドに代わって呼び出される静的なデフォルトメソッドをインターフェース内で指定可能にする，というものだ。

これらの主要項目以外に JSR が言及しているのは，

1. Project Coin を出所とする，より小規模な拡張項目。これには Josh Bloch 氏のコレクションリテラル(Collection Literals) に関する提案が含まれるだろう。配列の初期化と同様のシンタックスを持った，不変 (immutable) な List，Set，あるいは Map リテラルを追加する，というものだ。JSR-292 の新しい JVM 機能のためのソースコード構文も復活する可能性がある。
2. タイプアノテーション (Type Annotations，JSR308)。Java のアノテーションシステムを拡張し，任意の型にアノテーションを使用可能にする。
3. Date および Time の新 API (JSR 310)。
4. Swing の JDatePicker クラス。

Oracle に対しても Java の並列プログラミングのサポートや，さらにはフィルタ，マップとレデュースなど，一括データ操作の自動並列化サポートの完成に向けた作業継続が期待される。

Reinhold 氏は EclipseCon で，Oracle の最大の目標は Java が言語およびプラットフォームとしてナンバーワンであり続けることだ，と述べた。

Oracle では 20,000 人の Java 開発者が作業しています。データベースのコア以外はすべて Java で記述されているのです。もしそれが削減されるようなことがあれば ... 相当な再投資が必要になるでしょう。

Java 8 は 2012 年後半のリリースが期待されている。