前回レポートしたようにJava SEは、もともとJava SE 7に含まれるとしていた機能をJava SE 7とJava SE 8に分割するということになりました。ここでは、次に示すJava SE 7の代表的な機能を紹介します。
- Project Coin
- JSR 292 InvokeDynamic
そして、Java SE 8に含まれる次の2つの機能も紹介します。
- Project Jigsaw
- Project Lambda
JavaOne初日(9月20日)のThomas Kuris氏のキーノートにおいて、JavaFXはクライアント技術の中核として注力することが発表されました。
これをうけて、次バージョンのJavaFX 2.0では大幅な変更が発表されました。そこで、本レポートではJavaFX 2.0についても紹介することにします。
Java SE 7の新機能
Project Coin: Small Language Changes for the JDK
Project Coinは今まで使い勝手の悪かった文法を使いやすくすることを目標にしたプロジェクトです。
プロジェクト名のコインは小銭ですね。英語では小銭のことをSmall Changeといいます。つまり、文法の小さな変更(Small Change)を行うプロジェクトなのでCoinという名前が付けられたわけです。
ちなみに、動詞のCoinは「新しい言語(言葉)を作る」という意味です。ちょっと意味深ですね。
講演者はProject CoinのリーダーであるJoseph Dercyと、Maurizio Cimadamoreです。
Project Coinで扱うJava言語の変更は一般から公募され、70以上の提案がありました。その中から8提案が採用されています。また、Java SE 7だけでなくJava SE 8もターゲットに加わったことから提案が追加されています。
現在、すでにOpenJDKで実装されている項目は次の通りです。
- 2進数のリテラル
- 数値リテラルに対するアンダースコアを使った区切り
- 文字列をswitch文に使用する
- 可変引数に対する警告の変更
- ジェネリクス定義の簡略化
- 複数例外のキャッチと再スロー
- ストリームなどのクローズ処理の自動化
この中のいくつかを簡単に説明しましょう。
Java言語では16進数を数値の前に0xを付加することで表せます。同じように0bを付加することで2進数を表すことができるようになります。また、1_234_567_890のようにアンダースコアを使うことで可読性を高められるようになります。
ジェネリクスを使ったオブジェクトの生成では、ジェネリクスのパラメータが複雑な場合記述するのが大変です。そこで、次のように記述できるようになりました。
このように、newを使用したオブジェクト生成の部分はジェネリクスであることを明記すればいいだけになっています。この<>という書き方は、その形状からダイアモンドオペレータという呼び方をします。
最後のクローズ処理の自動化を使用すると、ストリームのクローズ処理を記述しなくてもよくなります。
tryの後のカッコの中にストリームの生成処理を記述しておくことで、try節を抜ける時にクローズ処理を行なうようになります。
現時点で実装されていない項目を以下に示します。
- コレクションのリテラル
- コレクションの要素に対する[ ]を使用したアクセス
- 巨大な配列
- 複数行からなる文字列
Project Coinでは、あくまでも文法の小さい変更だけにとどまっています。したがって、Java SE 8で採用が考えられているバリュークラスなどは変更が大きいため、Porject Coinでは扱わないようです。
Multiple Language, One Virtual Machine
このセッションは、Java VMで動的型付け言語をサポートするためのJSR 292 Supporting Dynamically Typed Languages on the Java Platformに関するセッションです。
講演者はBrian Goetz氏とJohn Rose氏。講演者の2人はJava VMのスペシャリスト。特にBrian Goetz氏は言語仕様の変更に関するセッションには引っ張りだこです。本レポートでもProject Lambdaに登場しています。
John RoseはJSR 292のスペックリードであり、JSR 292の参照実装を行うDa Vinci Machine Projectも率いています。
Javaはよく知られているように静的型付けの言語です。コンパイル時には変数の型、メソッドの引数や戻り値の型などは明確に定義しておかなければなりません。それに対して、JavaScriptやRubyのような動的型付けの言語もあります。動的型付けの言語では、型は実行時まで決まりません。
しかし、Rhino(JavaScript)やJRubyなどJava VMの上で動作させるスクリプト言語も増えてきました。
そこで、動的型付けの言語を容易にサポートしやすいように、新しくinvokeDynamicバイトコードが導入されることになりました。
invokeDynamicは、引数の型と戻り値の型を実行時に決めるメソッドコールに対して使用されます。実行時にはメソッドに対する参照を表すMethodHandleクラスを使用して、実行するメソッドを決定します。
後述するProject Lambdaのラムダ式も、このMethodHandleクラスを利用して実現されています。
Java SE 8の新機能
The Modular Java Platform and Project Jigsaw
Project JigsawはJARに変わる新しいモジュールを提供するためのプロジェクトです。このセッションはJava SE 8のチーフアーキテクトであり、Project JigsawのリーダーでもあるMark Reinhold氏が担当しています。
モジュールはJARと同じように複数のパッケージからなります。そして、モジュールの定義はmodule-info.javaに記述します。
module-info.javaに記述できる要素には次のようなものがあります。
- モジュール名とバージョン
- エントリークラス
- モジュールが依存するライブラリとそのバージョン
エントリークラスとはmainメソッドがあるクラスのことです。
JARを使っていた時には使用する外部のライブラリはすべてクラスパスで指定する必要がありました。モジュールではmodule-info.javaに使用するモジュールを記述できるので、モジュールのレポジトリの場所だけ指定するだけになりました。このため、クラスパスを指定する必要がなくなっています。
モジュールのレポジトリとして、Mavenのレポジトリも使用できるようです。
Project Lambda: To Multicore and Beyond
もともとProject LambdaはJavaにクロージャを導入することも目的としたプロジェクトでした。Project Lambdaを率いているのはMark Reinhold氏ですが、本セッションではBrian Goetz氏とAlex Buckley氏が担当しています。
なぜ今クロージャなのでしょうか。マルチコアの時代だからというのが、その答えです。
多くのコアが存在する場合、パフォーマンスを向上させるには、処理を各コアに分散して実行する必要があります。
JavaではExecutorServiceを使用した非同期処理の枠組みがあります。ExecutorServiceは粒度の大きいタスクを記述するのに適しています。
しかし、分散度を上げるにはタスクの粒度を小さくして、各コアに平均的に処理を振り分ける必要があります。そこで、Java SE 7では粒度の小さいタスクを非同期に実行するために、Fork/Join Frameworkが導入されます。
そして、ループを分散処理しやすくするために、Rubyなどで採用されている内部イテレータが導入されることになっています。
たとえば、卒業年度gradYearと成績scoreを保持したStudentクラスを考えます。この時、2010年に卒業した生徒の最高成績を求めるためには、2010年に卒業した生徒を振り分け(filter)、成績を取りだし(map)、最大値を求めます(max)。
赤字で示した部分がラムダ式です。#{ }がラムダ式を表し、->の前の部分に引数、後ろに処理を記述します。
このようにProject Lambdaでのラムダ式を使うと、単一メソッドを定義したアブストラクトクラスもしくはインタフェースの実装クラスを簡単に記述できます。なお、このような単一メソッドのことをSingle Abstract Method、略してSAMと呼びます。
つまり、ラムダ式はSAMタイプを簡単に表すための記法ということができるのです。
JavaFXの新たな道
JavaFX 2.0
JavaFXのはじめてのメジャーバージョンアップであるJavaFX 2.0は、前述したようにクライアント技術の中核となることが発表されています。このセッションではクライアントのチーフアーキテクトであるRichard Bair氏とJasper Potts氏が担当しました。
JavaFX 2.0の最も大きな変化は、JavaFX Scriptをサポートしないということです。
今までJavaFXのアプリケーションは、宣言的文法を採用したJavaFX Scriptによって記述してきました。しかし、JavaFX 2.0ではJavaFX Scrriptを捨て、Javaから扱えるようになったのです。
つまり、JavaFX 2.0はSwingやAWTと同じように、Javaのグラフィック技術の1つとなったわけです。
個人的には、JavaFX Scriptの簡潔な記述が気に入っていただけに、この決定は非常に残念です。しかし、JavaFXがなかなか浸透しない理由の1つがJavaFX Scriptであるという見方もできます。
この決定が吉と出るか、凶と出るかは、まだわかりません。
JavaFXがJavaのライブラリとなるため、JRubyやGroovyなどJava VM上で動作するスクリプト言語でもJavaFXを扱えるようになっています。
JavaFX 2.0の機能強化として、HTMLとの親和性の向上が図られます。たとえば、CSS 3のサポートや、JavaFXでHTMLを表示できるようになります。また、HTML 5のローカルストレージへの対応や、HTMLのDOMを操作できるようにするなどの機能強化が図られています。
JavaFX 2.0ではレンダリングエンジンも一新されます。JavaOne初日のキーノートで紹介されたムービーがYouTubeにもアップされているので、ぜひご覧になってみてください。
JavaFX 2.0は2011年の第1四半期にアーリーアクセス版、第2四半期にベータ版、そして第3四半期にリリース予定です。
おわりに
今年のJavaOneはJava SE、JavaFXに関してはロードマップが一新され、今後の見通しがはっきりしてきました。逆に、前回も言及したようにJava EEとJava MEはまだロードマップに具体性がないように筆者には感じられました。今後、どのようなロードマップが示されるのか、興味深いところです。
そして、Oracleが主催したはじめてのJavaOneということで、残念ながら手際の悪さも目立ってしまいました。これについては2回、3回と回を重ねることによって改善されていくのではないでしょうか。
Oracleが主催になったことで、JavaOne開催のレギュレーションが変化し、サンフランシスコ以外での開催も決まっています。今年の12月にはブラジルと北京で開催される予定です。また、来年にはロシアとインドでの開催も企画されています。
そして、サンフランシスコで開催される次回のJavaOneは、2011年10月2日から開催されます。来年はどのような新しい技術が飛び出してくるのか、興味はつきないところです。