Java SE 8の安定感

はじめに

これからソフトウェア開発を始めるプロジェクトでプログラミング言語にJavaを使う場合に、Javaのバージョンをどうしようかと調べたことを書き付けます。

開発するソフトウェアは、5年から10年、場合によってはそれ以上使われることが想定されます*1。

Javaのバージョンとライフサイクル

Oracle、Red Hat、Azul Systems、および Bell softwareが提供するJava SE Development Kitのサポート期限を調べてみました。

意外なことに、Oracleを除きJava SE 11よりもJava SE８の方がサポート期限が長いという結果になっています。

参照情報

• Oracle Java SE Support Roadmap
• OpenJDK のライフサイクルおよびサポートポリシー - Red Hat Customer Portal
• Azul Product Support Roadmap
• BellSoft Liberica JDK Support

ビルドツールとの相性

JDK 8環境では、各種ツールとの相性はよかったのですが、JDK 11環境となるとまだまだ整っていない部分があります。

NetBeansIDE

NetBeansIDE 8.2はJava SE８対応ですが、Java SE 11を使うには、ApacheNetBeans 10以降を使うことになります。しかしながら、NetBeansは8.2のリリースの後、OracleからApacheへ移管し、Apache incubatorのフェーズを経て2019年4月にApache正式プロジェクトへ昇格しました。

Java SE 8の開発であれば、NetBeansIDE 8.2が使えますが、Java SE 11の開発となると、現時点ではApacheNetBeans 11.3 になります。ただ、OracleからApacheへの移行に伴い、プラグインサイトの更新が追い付いていない感があり、安定して利用するには少々時間がかかりそうと思います。

JPMS対応

Apache Ant、Gradleは、JPMS（Java Platform Module Systems）対応が遅れており、ApacheMavenがやっと、というところです。

FindBugs

FindBugsは開発が停滞しており、JDK 11への対応が厳しいかなという状況です。SpotBugsに差し替えるのが有効な解決策の1つですが、NetBeansIDEに組み込むプラグインがまだない模様です。Eclipse用はありますが。

javapackagerの喪失

JDK 11ではjavapackagerが削除され、WindowsのインストーラーやLinuxのインストーラー（RPMパッケージ他）を作るのが面倒になりました。

外部ライブラリとの相性

Endorsed Standards Override Mechanismの廃止

クラスパスの設定にEndorsed Standards Override Mechanismを使っているライブラリはJDK 11では動かなくなります。（バッチファイル、シェルスクリプトファイルなので、クラスパス指定する等の修正をすれば動作） 例）JacORB 3.9

まとめ

Java SE 11がリリースされてから2年半が経過していますが、まだ周辺ツールが追い付いておらず、開発に使う場合の安定感はJava SE 8の方が高いです。

JDKのライフサイクルを見ると、Azul SystemsとBellSoftwareが提供するJDKについては、2021年9月リリース予定のJDK 17ですらJDK 8よりライフサイクルが短く、2024年9月リリース予定のJDK 23でようやくJDK 8のライフサイクルを超えるサポート期限となります。

もちろん、モジュールシステムや新しいAPI、新しい言語仕様、新しいGCなどの機能がどんどん取り込まれているので使いたい気持ちは山々なのですが、上述のとおりライフサイクルや開発環境（IDEだけでなく、品質チェック、ビルド、リリース等）を考慮すると、Java SE 11に移行すべきと言い切れないというのが現段階です。