待望のモジュール化機能、Jigsawが導入されるJava SE 9
Java SE 9ではProject Jigsaw、jshellなどの新機能が追加される。
一番の目玉はやはりProject Jigsawだろう。Java SE 8ではコンパクトプロファイルを利用することでランタイムの容量を削減できるが、コンパクトプロファイルは目的別にJava SE APIのサブセットを定義しているだけにすぎない。Project JigsawはJavaにモジュール化の概念を取り入れる機能で、任意のAPIのみを含むランタイムを作成可能だ。不要なAPIを含めないことでランタイムの軽量化、セキュリティの向上といった効果を得られるほか、モジュールを意識したプログラミングが可能になる。使用するAPIは、module-info.javaファイル内にrequires文で指定する。また、exports文により自作のパッケージをどこまで公開するかを指定可能だ。新たに追加されるjlinkコマンドを使えば、必要なAPIのみを含めたカスタムJREを作成することもできる。
jshellは文字通り「Javaのシェル機能」で、REPL（Read-Eval-Print Loop）環境を提供する。Javaプログラムはjavacコマンドでコンパイルし、javaコマンドで実行するが、jshellでJavaのコードを入力して実行し、その結果を表示するといった使い方が可能になる。わざわざコンパイルしなくても、ちょっとしたコードやロジックの確認に役立つ機能だ。
既存の機能に関してもさまざまな変更が行われている。
JavaのコードからHTMLドキュメントを生成するJavadocは、HTML5に対応する。また、ついに検索機能が導入されることになった。
注意したいのは、内部APIのカプセル化である。外部での使用を想定していない内部APIでもこれまでは制限なく使用できたが、Java SE 9からは隠蔽され、デフォルトでは直接使用できなくなる。ただし、代替APIが提供されていないものに関しては当分使用できる見込みだ。
jarファイルの構造が拡張されることも大きい。これまでjarファイルは1つのバージョンにのみ対応していたが、複数のバージョンに対応するjarファイルを作成できるようになる。
その他には、アプレットが非推奨となるほか、ヒープダンプを解析するjhatツールなどが削除される。
リリースが待たれるJava SE 9だが、JDK 9に移行する際には互換性に注意しなければならない。バグの修正、セキュリティの改善、サポートするバージョンの変更など、さまざまな原因によりアプリケーションの非互換性が生じる可能性がある。
Java SE 9では内部APIのカプセル化に伴い、sun.misc.*とsun.reflect.*の大部分が直接使用できなくなる。対策としては、jdepsツールでクラスの依存関係を調べ、該当箇所を修正する。どうしても使用したい場合は、実行時のコマンドラインでフラグを指定することで暫定的に対処する。
モジュール化の導入により、JREのディレクトリやファイルの構造が変更され、ランタイムコアファイル（rt.jar）が削除されることにも注意が必要だ。例えば、ファイル名やファイル名の内部構造、インストールフォルダなどに依存するコードは修正して対処しなければならない。
コンパイルに関しても新しく「one plus three back」というポリシーが導入され、対応可能なバージョンが制限される。現バージョンと3つ前までという意味だ。すなわち、JDK 9では6、7、8、9までがコンパイル可能で、5には対応していない。
また、JDK 7と8には付属していたJava DBが非搭載となる。JDK 9では別途Apacheのサイトから入手する必要がある。
Java SE 9ではアプレットが非推奨となるため、JDK/JRE 9環境でアプレットを実行すると「プラグインが非推奨」というメッセージが表示される。
クラウド、マイクロサービスに対応するJava EE 8
Java EE 8については2016年10月に修整提案が発表され、JCPのルールに従って順次コミュニティとともに検討が進められている。Java EE 8およびJavaEE 9で目指すのは、将来的にはクラウド、マイクロサービスといった、新しいスタイルのアプリケーション開発に対応することであり、断片的にテクノロジーを実装したプラットフォームではなく、プログラミングモデルから、アプリケーションのパッケージング、移植性までを包括して構成し、実績のある標準的なテクノロジーを使用することを方針としている。
Java EEはオンプレミスのエンタープライズ環境として圧倒的なシェアを誇るが、クラウドが広く使われるようになった状況を受け、今後はオンプレミスとクラウドの両方で利用できるプラットフォームへと進化していかなければならない。Java開発者は、目まぐるしく変わり続けるビジネスニーズを満たすために、これまでのモノリシックなアプリケーションから脱却し、マイクロサービスにも取り組んでいく必要がある。
Java EEが今後目指す方向としては、多種多様なクライアント、ステートレスサービス、多彩なデータソースなどが挙げられる。
クライアントは1つに限定せずに、モバイル端末を含む複数のクライアントをサポートすべきだ。そのためにJavaEEではHTTP 2.0、JSON、REST、XHRといった技術に対応する。また、JavaだけでなくHTML5、JavaScriptなど複数言語の使用も必要となる。
マイクロサービスは、複数の小さなサービスを組み合わせて1つの機能を提供する。各サービスは互いに独立しており、あるサービスで障害が発生しても他のサービスには影響しない。Java EEでは従来はステートフルアプリケーションが主流であったが、今後はマイクロサービスのようにステートレスアプリケーションを主流としていく必要がある。サービスの連携には、JAX-RS（REST）、JAX-WS（Webサービス）、イベント通知などを利用する。
データソースに関してはJDBCを介してRDBを利用することがほとんどであった。これに加えてNoSQLデータベース、データストリーム、TSDB（時系列データベース）も利用できるようにしていく予定だ。
Java EEの従来のアプリケーションは、アプリケーションサーバ上でインスタンスを生成し、設定ファイルやセッション状態などは内部で保持・管理するという形で稼働する。今後は、クラウドネイティブな形式でコンテナを使ってインスタンスを生成し、設定ファイルやセッション状態はアプリケーションの外、すなわちクラウド側に持たせる仕組みが必要となる。Java EE 8あるいは9では、アプリケーションをコンテナ上にデプロイし、オーケストレーションツールで制御するという環境の導入が進むと思われる。
伊藤氏は、Java EE 8あるいは9において想定されるプラットフォームを提示。Java EE 8では、GlassFishを参照実装とするJava EE 7をベースに、CDI、JSF、JAX-RS、JSON-Pなどの更新、JSON-B、セキュリティ、設定、ヘルスチェックなどの追加、JMS、MVCなどの削除が提案されている。ロードマップではJava EE 8は2017年内、さらにJava EE 9は2018年内に提供することを目標としていることが述べられ、セッションは終了した。
お問い合わせ
日本オラクル株式会社
- TEL: 0120-155-096（Oracle Direct）
- コーポレートサイト
