Java 10 - これまでの経緯

Java 9のリリースからちょうど2ヶ月が経った。新しいスケジュール(http://openjdk.java.net/projects/jdk/10/)により、Javaの次のバージョンは今からたった4ヶ月後だ。Java 10の全スコープはまだ確認と整理中である。これが意味することは、まだ重要な変更がGAまでの間にリリースのスコープと内容に入る可能性があるということだ。しかし、Java 10に入れるように求めるのが適切であるような機能を、開発者が残り4ヶ月で発想を得ることはできるだろうか。

新機能と拡張は、JEP、Java拡張プロセスか標準化提案のためのJavaコミュニティプロセス(JSR)を通じて管理される。短い時間尺度とそれゆえの小さなスコープのため、Java 10の変更はJEPとして始まり、JEP番号で管理されるはずだ。

Java 10でもっとも含まれる可能性が高い機能は、JEPで現在対象の状態がTargetedもしくはProposedのものだ。現時点で以下の機能が該当する。

• 286: ローカル変数の型推論
• 296: JDKフォレストの単一リポジトリへの統合
• 304: ガベージコレクタインタフェース
• 307: G1でのパラレルフルGC
• 310: アプリケーションのクラスデータ共有
• 312: スレッドローカルのハンドシェイク

これらの中で、JEP 296は単に整理であり、JEP 304は異なるガベージコレクタに対してコードの分離を高め、ガベージコレクタにきれいなインタフェースを導入する。

後者が意味することはベンダがより簡単に特定のGCアルゴリズムを含む、もしくは除外したJDKビルドを作成できるということである。新しいGCアプローチ、たとえば開発中のShenandoahやZGC、Epsilonで、これは意味をなす。コミュニティ内にはコンカレント・マーク・スイープコレクタ(CMS)を非推奨にし削除さえするという作業がある。今のところ本番向けの品質でそれを置き換える適切なものはないのだが。

もっとも興味を引くかもしれない変更はJEP 286だ。型推論を拡張することで開発者がローカル変数の宣言においてボイラープレートを減らすことができる。これが意味することは以下のコードが次のJavaのリリースで有効となるということだ。

var list = new ArrayList<String>();  // infers ArrayList<String>
var stream = list.stream();          // infers Stream<String>

このシンタックスはローカル変数に制限されるだろう。初期化やforループ内のローカル変数といったところだ。

これは単にソースコードのコンパイラ内に実装されるシンタックスシュガーだ。意味論的な重要性はない。にもかかわらず、実験ではこの機能がJava開発者の間で活発な議論を引き起こす可能性が高いことを示している。

残る3つの変更はすべてパフォーマンスの上で、可能性として小さいけれども、影響がいくらかある。

JEP 307はG1ガベージコレクタでの問題を解決する。現在のJava 9でのG1のフルGCの実装は単一スレッドでの(シリアルな)アルゴリズムを使っている。
これが意味することはG1が一度でもフルGCにフォールバックしたなら、重いパフォーマンス上の衝撃が待ち受けるということだ。JEP 307の目的はフルGCアルゴリズムを並行化することで、G1のフルGCという起こりそうもないイベントにおいて同一数のスレッドを並列コレクションとして使えるようにするためである。

JEP 310はクラスデータ共有(CDS)という機能を拡張する。これはJVMが一連のクラスを記録し、それらを処理して共有アーカイブファイルとするものだった。このアーカイブは次回起動時に起動時間を短縮するためJVMプロセスとメモリマッピングされる。ファイルはまたJVM間で共有され、同一ホスト上で複数のJVMが実行されるとき全体のメモリフットプリントを削減できる。

この機能はJava 5からあったが、Java 9では、CDSはアーカイブされたクラスをロードするブートストラップクラスローダだけに許可されていた。JEP 310の目的はこれを拡張し、アプリケーションやカスタムクラスローダがアーカイブファイルを使えるようにする。この機能は実はすでに存在しているが、現在はOracle JDKでのみ利用可能で、OpenJDKでは利用できない。
それゆえこのJEPは基本的にオラクルのプライベートソースからオープンなリポジトリに機能を移行することとなっている。Java 10以降、通常の(LTSでない)リリースはOpenJDKのバイナリである。オラクルがこの機能をオープンなリポジトリに移すということは、彼らにはこれを使っている実際の顧客がいることを暗に意味しており、そのためオラクルはOpenJDKバイナリ上で今後そうした顧客をサポートする必要があるだろう。

最後に、JEP 312はVMパフォーマンス改善への下準備だ。アプリケーションスレッド上でグローバルなVMのセーフポイントを実行せずにコールバックを実行できるようにする。これはJVMが単にすべてのスレッドを停止するのではなく、個々のスレッドを停止するということを意味するだろう。これを可能にする小さな、低レベルの改善のいくつかは、以下のことを含んでいる。

• スタックトレースのサンプル取得(たとえばプロファイリングのため)の影響削減
• シグナルへの依存削減によるよりよいスタックトレースのサンプリング
• バイアス状態の無効化の際、個々のスレッドの停止のみとなるバイアスロックの改善
• JVMからメモリバリアをいくつか削除

全体として、Java 10は大きな新しい機能やパフォーマンス改善は何も含んでいないように思える。これはおそらく期待されていることでもある。膨大な変更に代わって、新しく、より頻繁で、漸進的なリリースサイクルにおける最初のリリースを表現しているのだ。