Java SE 7のスペックリードを務めるMark Reinhold氏

次期JavaプラットフォームであるJava SE 7は、Javaがオープンソース化されてから初めてのメジャーリリースとなる。それだけに追加される機能や言語仕様の変更が気になるところだが、開発者にとってとくに押さえておくべきポイントはどこだろうか。6月2日(米国太平洋夏時間)より4日間に渡って開催された2009 JavaOne Conferenceのテクニカルキーノートおよび関連するセッションにおいて、Sun Microsystems Principal Engineer、Java SE & Open JDKのMark Reinhold氏はJava SE 7で提供される新機能のポイントを語った。

Reinhold氏はJava SE 7そしてJDK 7における新機能のポイントとしてとくに以下の3つの要素を挙げている。

  • モジュール化への対応
  • 多言語に対応したJVM
  • 生産性の向上

モジュール化への対応

モジュール化については「JSR 294: Improved Modularity Support in the Java Programming Language」と「Project Jigsaw」2つの方面から対応が進められている。JSR 294では言語および仮想マシンレベルでのモジュール化対応のための仕組みが用意される。Project Jigsawの方は、JSR 294をベースとしてJDK 7のためのモジュールシステムを構築するプロジェクトである。

以前、小誌の連載記事においてJava SE 7におけるモジュール化対応の経緯を説明したが、ちょうど同時期にJSR 294の再度の見直しがスペックリードのAlex Buckley氏から提案されていた。その結果、JSR 294ではモジュールシステムで利用するための基盤となる仕組みを整備するという方針にまとまった。具体的には、Javaの言語仕様にモジュールの作成および依存関係の定義のための新しい構文やキーワードが追加される。また、javacコマンドにおいてもモジュールのための新しいオプションが追加される予定だという。

一方でProject Jigsawが目指すのは、JDKやJava実行環境、そしてJavaアプリケーションをモジュール単位で利用できるようにする仕組みの構築である。たとえばGUIを利用しないアプリケーションではAWTやSwingに関連した機能は必要ない。そこでJDKそのものをモジュール単位に分割し、必要なモジュールのみをインストールしてあればアプリケーションが実行できるようにする。これによってインストールするランタイムや開発キットのサイズを最小限に抑えることができる。

JDKのモジュール分割と依存関係のイメージ

Reinhold氏によれば、現行のOpenJDK 6の場合、Javaランタイムのダウンロードサイズは13Mバイト以上、JDK全体では70Mバイト以上に上るという。モバイル機器などへの対応を考えた場合、このサイズはあまりにも巨大すぎる。そのためモジュール化対応は不可欠であると同氏は指摘している。

なおOpenJDKプロジェクトにおけるProject Jigsawチームでは、JSR 294の参照実装と、Jigsawの設計および実装の双方を行っている。したがって実質的にはこの2つの取り組みはセットで進められていると考えてもいいだろう。

多言語に対応したJVM

近年Javaの新しい方向性として注目されているのが、JVM上で動作する"Java以外の言語"の実装である。すでにJDK 6にはJavaScriptエンジンであるRhinoがバンドルされているほか、Ruby実装であるJRubyやPython実装であるJythonなどはすでに多くの開発者に使われ始めている。これらの実装には、Javaが持つ堅牢性や豊富なクラスライブラリを保持しつつ、各言語が持つ手軽さなどの特徴を享受できるというメリットがある。

Javaを取り巻くさまざまな言語

Java SE 7ではJVM上で動作する動的言語をサポートするために「JSR 292: Supporting Dynamically Typed Languages on the Java Platform」が導入されることになっている。JSR 292の中心になるのがinvokedynamic命令の実装の実装で、これによって動的な型付けの実装が容易になるという。このJSR 292の実装も含めて、JVMにおける多言語サポートはOpenJDKのサブプロジェクトである「The Da Vinci Machine Project」で進められている。

また、JDK 7ではRhinoに加えてさらに他の言語実装をバンドルすることも検討されている。具体的にどの言語が採用されるのかは現時点では決まっていないが、前述のJRubyやJython、Javaその親和性が極めて高いGroovyなどが有力な候補となるだろう。

生産性の向上

生産性の向上についてもさまざまな試みがなされているが、Reinhold氏が特に言及したのがジェネリクスにおける型推論の拡張だ。たとえばコレクションクラスのインスタンスを生成するリスト1のようなコード考えてみる。非常に長い。

リスト1

Map<String, Map<Integer, List<String>>> map
            = new HashMap<String, Map<Integer, List<String>>>();

これを、型推論の機能を拡張してリスト2のように記述できるようにする。

リスト2

Map<String, Map<Integer, List<String>>> map = new HashMap<>();

「<>」はそのために追加する新しい記述方法だ(開発チームでは"ダイアモンド"と呼んでいるらしい)。このとき、mapの型はコンパイル時にコンパイラが推測して自動的に決定する。

このほかにもJava SE 7では、開発者の手間を減らすためにさまざまな追加機能が検討されている。このジェネリクスの例のように単独でJSRを取得するほどでもない細かな変更については、OpenJDKのサブプロジェクトである「Project Coin」において検討および実装が進められている。リリーススケジュールによれば、Project Coinの成果はマイルストーン6の段階でOpenJDK本体にマージされる予定となっている。

Java SE 7にはここで挙げた以外にもさまざまな機能が追加される。一時は有力かと思われたクロージャの採用が見送られるなど紆余曲折はあったが、ここにきて大体の方向性が決定しつつある。リリース後の速やかな対応のためにも、できるだけ早い段階でチェックしておきたい。

現時点でJava SE 7に追加される予定となっている機能の数々