待望のJava 9.0が今週リリースされる

待望のJava SEの次のリリース、バージョン9が2017年9月21日にリリースされ、大きな変更がいくつかある。

JDK 9の鍵となる変更は、オラクルによれば"名前があり自己記述的なコードとデータの集合で、Javaプログラミングコンポーネントの新しい種類となるモジュール"の導入だ。モジュール技術の主な狙いはJavaアプリケーションとコアのJavaランタイム自身のサイズと複雑性を減らすことだ。この目標を達成するために、JDK自身がモジュール化された。パフォーマンスやセキュリティ、メンテナンス性の改善を意図したオラクルの取り組みだ。

Java 9のモジュールをサポートするために、そのルートディレクトリにmodule-info.classファイルを持つ新しいモジュラJARファイルも導入された。オラクルはまたモジュールの集合をカスタムランタイムイメージにアセンブルし最適化できるツールを導入した。その際完全なJavaランタイムが存在している必要はない。他の変更としてはモジュール化の結果としてJavaランタイムイメージからrt.jarとtools.jarが取り除かれている。

InfoQはBen Evans氏にJava 9.0でのモジュールシステムにおける彼の考えについてインタビューした。氏はJavaコミュニティプロセス(JCP)のExecutive Committeeのメンバーである。

Evans氏「差し迫ってリファクタリングが必要なアプリケーションはモジュール化の対象としてもっとも適切だろうと私は考えています。もしすでに溶岩流/神クラス/ストーブパイプシステムといったアンチパターンにはまっておりステークホルダーがそれを知っているなら、完全にリファクタリングし、(ただリファクタリングしJava 8に移行することに比べて)完全にモジュール化するという解決に向かって努力をしていくことには価値があると彼らを説得するのはより簡単でしょう。」

オラクルがJava 8を長期間サポートのリリースとし2022年までサポートすると発表して以来、Evans氏は多くのアプリケーションがJava 8のとどまりJava 9へまったくアップグレードしないかもしれないと考えている。Evans氏はバージョン8での開発やビルドのツールチェーンをやめて本番でJava 9のランタイムを使うアプリケーションもあると付け加えた。

「これは特定のアプリケーションにとってとても意味があることかもしれません。たとえば私は文字列データが40Gにもなる巨大なヒープを持つeコマースサイトを見てきました。Java 9の文字列圧縮はメモリ使用量を半分にします。すると次にGCのパフォーマンスによい影響を与えるでしょう。いくつかのアプリケーション(おそらく巨大なSolrの導入といったような)にとって、これだけでランタイムを9にアップグレードする価値があるかもしれません。」

Java 9は今までデフォルトだったParallel GCに代わりG1をデフォルトのガベージコレクタにした。Evans氏はこの変更にこうコメントしている。

この変更は重要に違いありません。なぜならG1はParallel(基本的にアプリケーションスレッド上では動作せず、メモリ管理で仮想的にすべての処理をするためにGCスレッドを頼りにします)よりもアプリケーションスレッド上でより動作するからです。これが意味することはG1への切り替えはアプリケーションスレッド上での余分な作業を持ち込むことになり、アプリケーションのパフォーマンスに直接影響します。

多くのケース(おそらくほとんど)でこのパフォーマンスへの追加のオーバーヘッドは問題となりません。しかし、現場の仕事でかなりの割合でParallelからG1へ移行した際に明らかなパフォーマンス低下が見られたのを私は見てきました。こうしたアプリケーションのいくつかにとって、このパフォーマンス低下は許容できないもので、そのためそれらはG1コレクタへ移行できません。G1がデフォルトになることで、現段階ではJava 9へ移行するすべてのアプリケーションに潜在的に影響します。

InfoQはMartijn Verburg氏に質問した。氏はJClarityのCEOでにロンドンJavaユーザグループの幹事の1人である。巨大なコードベースをモジュールにリファクタリングする際のアドバイスについて質問した。

Verburg氏「ええ、あなたが扱っているような巨大なコードベースはいくつかのモジュール構造に似たもの、OSGiやMavenモジュール、JBossモジュールまたは単に明確なパッケージとインタフェース構造という一連の社内ルールですでに分割されているといいのですが。」

Verburg氏はよい共通モジュールについてのアドバイスをいくつかし、また開発者がJava 9のモジュールシステムを採用する際に気をつけるべきことを指摘している。

• Paul氏とSander氏の書籍であるJava 9 modularityを読もう。これは手引として決定版だ。やり遂げたことすべてとモジュールやパッケージ、JAR間の関係がどのように動作するのかをカバーしている。
• モジュール境界によく考えられたインタフェースを定義し、そこにコーディングすること。
• パッケージを分けない。すなわちパッケージを2つのモジュールにまたがって分割しないこと。Adopt OpenJDKプログラムのPatrick Reinhart氏は既存のコード上で実行できる検出ツールを作ってくれている。
• 循環依存がないか確かめること(Jigsawはそれを許可していない）。
• モジュールがソースに配置される方法は今までとは違って見える。ビルドツールが適切に処理できるか確かめること。
• Jigsawはバージョンをサポートしていない。

Verburg氏によると、鍵となることは循環依存を修正し、パッケージを分け、確実にインタフェースにコーディングするということだ。これはJigsawでのモジュール化を試みる前に既存のコードベースにすべきことである。彼はまたモジュール化されたアプリケーションだけがJava 9で実行できるという誤った話について述べた。

人々が誤って話している、Java 9で実行するためにはモジュール化されたアプリケーションである必要があるという話が広まっていることに、少し不安があります。これは単純に真実ではなく、既存のクラスパスベースのアプリケーションもJava 9でうまく実行できます。セキュリティ制限が2つ3つあります。いくつか特別な実行フラグを立てる必要があるかもしれない、ということを意味します(Javaの内部のものなどに安全な手法でアクセスするようコードをリファクタリングするまで)。しかしもっと言えば停止するのではなくデフォルトでは警告が出るだけです(Java 10ではより強制となるでしょう)。

Verburg氏はJigsawはJavaをより前進させることができる基礎であると考えている。そしてこれを実現するために長年に渡りたゆまず努力したMark Reinhold氏やAlan Bateman氏、Mandy Chung氏やJigsawチームのメンバーを信じている。

Java 9はjshellツールも導入した。このコマンドライン環境はJavaプラットフォームにRead-Eval-Print-Loop (REPL)をもたらす。これは即時の結果とフィードバックでプロトタイプやコーディングオプションの調査をやりやすくすることを意図している。

Verburg氏とEvans氏の両者ともJava 9でjShellが含まれることを喜んでいる。しかしHTTP/2がJava 9ではインキュベーターモジュールとして出荷されることに失望を述べている。かなりのコミュニティがこの機能に興味を持ち助力を申し出るとすると、オラクルがHTTP/2をGAとして出荷するために十分なエンジニアリングリソースを充てるべきであるとEvans氏は考えている。

JDK 9でもたらされる変更の完全なリストはオラクルのウェブサイトにある。6ヶ月のリリースサイクルへの移行発表で、Java 9のリリースはこれまでJavaに関するオラクルの管理を特徴づけてきた"主要"機能で駆動される最後のリリースとなる。Javaの進化の次のフェーズはより短く、機能指向のリリースによって駆動される方向へ向かうように思える。これによってサーバサイド技術を牽引するポジションをJavaが保てるかどうかはまだわからない。