Edited at

Javaエンジニアが Java 11 リリースに向けて備えておくべきこと

~~ イマドキな開発スタイルに乗りきれていないエンジニアのために ~~


JDKのバージョンアップに備える

JDKの機能リリース・サイクルが6か月サイクルになりました。

LTSバージョンや、有償サポートを受けていない限り、新しいバージョンがリリースされれば、以前のバージョンがサポート終了となります。

長期にわたる開発スパンの途中にJDKの新バージョンがリリースされることは容易に想像でき、あらかじめ考慮しておく必要があります。

開発期間中はバージョン固定で開発を進めることもできますが、開発したソフトウエアのリリースや、システムのC/O時点では最新のJDKバージョンであることが求められます。

したがって、リグレッション・テストがサイクリックに実施できる開発インフラの整備が必須になります。

Java 11になると、これまで非推奨(Deprecated)としてマークされているものの、継続して利用できたAPIが削除される可能性があります。

こういった変更が与える影響を素早くキャッチアップできる必要性も出てきます。


Java 9 でビルドし、Java 11への移行時の影響を予測する(2018/05/21 追記)

Java 9 の時点で、Project Jigsawなどの変更もあり、既に削除されているAPIや、これまで参照できていた内部実装クラスが参照できなくなったりといった変更が発生しています。

Java 9 が入手できる今のタイミングでJava 9でのビルドや動作確認などしておき、Java 11への移行に予め備えておきましょう。Java 11への移行時のインパクトが少なくて済みます。


Java 11で削除されるAPIの代替が必要

Java 11 の変更内容として、JEP 320が含まれており、 Java 9 で非推奨になったJava EEやCORBAなどが削除されます。Java 8 からの移行を検討するにあたっては、これらの代替になる外部ライブラリへの書き換えを行う必要があります。

Java EEにおいては、Jakarta EEに移管されることになっていますから、パッケージ名の書き換えなど必要に応じて対応することになります。


削除される対象のパッケージ


  • java.xml.ws (JAX-WS、関連技術SAAJおよびWebサービスメタデータ )

  • java.xml.bind (JAXB)

  • java.activation (JAF)

  • java.xml.ws.annotation (共通注釈)

  • java.corba (CORBA)

  • java.transaction (JTA)

  • java.se.ee (上記6つのモジュールの集約モジュール)

  • jdk.xml.ws (JAX-WS用ツール)
    jdk.xml.bind (JAXB用ツール)


依存ライブラリのバージョンアップに備える

同時に、依存する外部ライブラリのバージョンアップに備える必要もあります。

セキュリティパッチ・リリースに備えることも当然ですが、JDKのバージョンアップに合わせて、これらの外部ライブラリもバージョンアップされる事は容易に想像できます。

やはりここでも、リグレッション・テストが容易に実施できる必要性があります。

依存ライブラリのバージョン管理には、パッケージマネージャーや、そういった機能を備えたMaven や Gradleといったビルドツールを使います。


リグレッション・テストにコストをかけない

ヒトの手で1つ1つテストケースを消化するのは、もはや時代遅れです。

リグレッション・テストをサイクリックにかつ容易に実施するには自動化する以外、他にありません。

すべてのソースコードをビルドして、すべてのテストコードを実行するのを、開発作業PCで実施するのは、現実的ではありませんので、専用のサーバーを用意します。

ただし、カバレッジ計測や、品質確保のための再利用可能なテストコードを書く方にコストをかけることになります。

(決して、TDDやTest-Firstである必要はありません。)

DBなどに影響を与えるようなコードをテストする場合は、モックを使うか、テスト終了時にしっかり後始末できるテストコードを書くように心がけるのは言うまでもありません。

画面のあるシステム開発では自動化が難しい部分もあります。

ココでは、『JDKや依存ライブラリのバージョンアップが与える影響を素早くキャッチアップする』事を目的として、『今まで通り動くよね』がテストできれば良いこととします。


CI(継続的インテグレーション)ツールの活用

ソースコードのビルドや、テストコードの実行などを自動化するために、JenkinsやTravis CIなどのCIツールを導入しましょう。

ソースコードの変更が反映されたら直にビルドされるように設定します。

静的検査の実行や、テストコードの実行、カバレッジ計測など、開発作業の裏で実行されるようになります。

また、クラウド(IaaS,PaaS,SaaSなど)や、SDI(Software Defined Infrastructure)、Dockerなどの仮想化技術をうまく活用することで、開発リソースの変更が反映された検証環境を素早く構築することも可能です。


まだSVNを使っているなら、Gitに乗り換える

いまどき、開発リソースのバージョン管理をしていないなんてあり得ないと思いますが。

SVNで出来なかったことが、Gitではできます。SVNで出来たことはより便利になっているのがGitです。

バージョン管理、リビジョン管理が煩雑になる事は容易に想像できます。

GitHubや、GitBucketなど、Pull-Request(マージ・リクエスト)機能を持つGitサーバーの運用を今すぐにでも開始しましょう。

構成管理が厳格にできないのであれば、なおさらです。


2019年1月 Oracle JDK 8 公式アップデート終了に向けて

以下のいずれかを選択する事を検討しましょう


  • Oracle JDK 8 の有償サポートを受け、延長する

  • Oracleの有償サポートを受け、 Oracle JDK 11へ移行する

  • 無償のOpenJDK 11 へ移行する(ただし、LTSにならない場合は、6か月サイクルでの更新計画を立てる必要がある)


Java11 のリリースをワクワクしながら待とう!(2018/09/08 追記)

ココにあるスケジュールでは、一般利用が可能になるのは、9/25とあります。

もうじきですね・・・。万全な体制を整えて、ワクワクしながら待ちましょう。

Fedora27のUpdatesリポジトリではリリース候補版が提供されているようですネ。