原文はこちら。
The original article was written by Aurelio Garcia-Ribeyro (Senior Director of Product Management, Oracle).
https://blogs.oracle.com/java/post/choosing-the-right-jdk-version

Introduction

JDKを最新の状態に保つことは、単に重要なだけでなく、賢い選択でもあります。最新の状態を維持することで、最新のセキュリティとパフォーマンスの強化の恩恵を受けることができます。つまり、たとえコードが同じままであっても、ユーザーのセキュリティとアプリケーションのエクスペリエンスが時間とともに向上する可能性があるのです。したがって、すべてのJavaユーザーに対し、サポート期間内のバージョンを使い続け、Critical Patch Updateセキュリティ・パッチを遅滞なく適用することを強く推奨します。

最新の状態を維持するには、2方法があります。

• 同じJavaバージョンのアップデートを適用する（アップデート）
• 新しいJavaバージョンを採用する（アップグレード）

このエントリでは、アップデートのタイミングとアップグレードのタイミングについて考えます。

本題に入る前に、この投稿で使用するいくつかの用語を明確にしておくことが重要です。機能リリース（Feature Release）とは、APIやツール、その他の機能が追加されたり、非推奨になったり、削除されたり、といったJava SEの仕様が変更される可能性のあるリリースのことです。 します。機能リリースは、一般的にJDK 21、JDK 17、JDK 8といった感じで番号で呼ばれます。Oracleでは、Oracle JDK 21 など、特定の機能リリースのLong Term Support（長期サポート）を提供しています。更新リリース（Update Release、更新リリース）は、JDK 21.0.3、JDK 17.0.11、JDK 8u411など、機能リリースに対して行われる更新です。

Updating versus Upgrading

Updating

ほとんどの場合、アップデートは簡単な作業です。非互換性のリスクは小さく、システムの安定性とセキュリティに明確な利点があり、時にはパフォーマンスを向上させる修正もありますし、以下のような目的でアップデートが必要な場合があります。

• ファームウェアやOSの変更を管理するため
• 新しい暗号アルゴリズムを獲得して潜在的に安全でないアルゴリズムを無効にするため
• 新しいハードウェアを使用するため、など。

Upgrading

アップグレード（例えばJDK 21からJDK 22へのアップグレード）は、アップデートよりも高コストになる可能性がありますが、それに比例してメリットも高くなる場合があります。

• 開発者：新しい言語機能、新しいツール、新しい API を手に入れ、既存のアプリケーションのコーディングと保守が容易になります。
• 既存のアプリケーション：コードを変更したり、アプリケーションを再コンパイルしたりしなくても、新しいJDK機能リリースによってパフォーマンスが大幅に向上する可能性があります。
• 新しいJDKのバージョンは、ワークロード次第ですが通常、起動が速くなり（スタートアップ）、ピーク性能に達するのが早くなり（ウォームアップ）、実行が速くなり（スループット）、利用可能なリソースをより有効に活用できるようになります。
• また、監視やデバッグのための優れたツールが導入されたり、より新しく特殊なデプロイメント・モデルが実現可能だったりする場合があります。

この裏返しとして、機能リリースでは以下のようなことが発生する場合があります。

• 古いAPIの削除または廃止
• 古いツールの廃止
• 古いOSやアーキテクチャのサポート停止
• サードパーティのツール、ライブラリ、ツールチェーンのアップデートが必要

こうしたコストやリスクを回避するため、開発者や管理者の中には、単一のリリースを長期間使い続けることを選択する人もいます。例えば、Oracle JDK 8は2014年にリリースされ、少なくとも2030年12月までOracleによってサポートされますが、どのバージョンもいずれはサポートが終了するため、アップグレードを延期することはできても、それなりの計画を立てる必要があります。

一見したところ、Javaを利用する利点を最大化するために、ユーザーは2つの相反する目標を満たす必要があるように見えます。既存のアプリケーションは、（JDKを最新の更新リリースにアップデートする以外に）できるだけ少ない変更で、できるだけ長く動作する必要があります。一方、開発者は、新しい機能リリースに付属する新しい言語機能、API、開発プラクティスにアクセスすることができれば、生産性が向上するでしょう。一般的なプラクティスや既存のサンプルコードとますます相容れなくなっている古いコーディング・プラクティスを、いつまで開発者に使ってもらうべきでしょうか。どれぐらいの性能向上であれば、そしてどのような領域であれば、新バージョンを採用するコストが正当化されるのでしょうか。これらの目標のバランスをとる最善の方法はどのようなものでしょうか。

現実には、

あらゆる場所で単一のJavaバージョンを使用する

という自身で課した要件から解放されれば、以下のガイドラインを使用して、両方の世界のベストを得ることができます。そのためにも、現在利用中のOracle JDK機能リリースのままでいくか、いつアップグレードするかを決める必要があります。

Use Multiple Runtimes

すべてのJavaアプリケーションに単一のJDK機能リリースを義務付ける必要はありません。かつて、Javaのメジャー・バージョンが数年に1つしかなく、ほとんどのハード・ドライブがメガバイト単位で測定されていた時代には、各Javaアプリケーションが独自のJavaランタイムを持つことは珍しいことでした。むしろ、サーバー内のすべてのアプリケーションが単一のJavaランタイムを共有するのが一般的で、1つのアプリケーションのJavaランタイムを切り替えることは、すべてのアプリケーションのJavaランタイムを変更することを意味したのです。あるアプリケーションをアップグレードしても、他のアプリケーションも早々にアップグレードを余儀なくされないようにするため、組織は通常、すべてのアプリケーションに対して特定のJavaバージョンを標準化することを選択します。新しいランタイムへのアップグレードを望む組織には「フラグデー」があり、本番と開発の両方で、すべてのアプリケーションが同時に同じ新しいランタイムにアップグレードしなければなりませんでした。

このようなall or noneのアップグレード方針は、もはや意味がありません。最近のサーバーには、以前より多くのメモリとストレージが搭載されています。今や、システムの分離を犠牲にせずハードウェアを共有する方法をコンテナーが提供してくれています。アプリケーションをコンテナー化し、それぞれが独自のJavaランタイムを持てるようにするのが一般的になっています。jlinkやjava packagerのようなツールを使えば、アプリケーション開発者がJavaランタイムをアプリケーションにバンドルすることが簡単です。もはや、すべてのユースケースに単一のJava機能リリースを使う必要はありません。すべてのランタイムが最新の更新リリースに対応していることを確認し、セキュリティとパフォーマンス強化の恩恵を受けられるよう、End-of-life（EOL）バージョンを使用しないことが重要です。

Application-Specific Guidelines

アプリケーションが自身のライフサイクルのどこに位置しているかによって、どのJDKバージョンでアプリケーションを動作させるが決まります。

For actively working on an application
（活発に開発中のアプリケーションの場合）

開発者がアプリケーションを活発に開発中であれば、より新しい機能リリースへのアップグレードを求めることは妥当なことです。アプリケーションの開発がそれほど活発でなくなったら、アプリケーションのパフォーマンス向上によるコスト削減や、長寿命アプリケーションの場合、使用しているリリースのサポート終了が近づいているなどの正当な理由がない限り、開発者に新しい機能リリースへのアップデートを求めるべきではないでしょう。本番稼動している重要で安定したアプリケーションであれば、LTSリリースを使うべきです。

For new, complex projects that won’t be put into production for at least a year
（少なくとも1年間は本番稼動しない、新しく複雑なプロジェクトの場合）

少なくとも1年間は本番稼動しない、新しく複雑なプロジェクトの場合、LTSでなくても、最新のJDK機能バージョンを使うことを目指しましょう。次のLTSが登場するまでにコードが最終化されない可能性があるためです。最新のリリースで開始し、次のLTSを早めに採用することで、安定したLTSリリースでコードを実行できる期間を最大限に延ばすことができます。使用したいサードパーティーのツールやライブラリが使用予定のJDKバージョンでサポートされていることに注意する必要があるのはいつも通りです。

For new code meant to be released within a year
（1年以内に新しいコードをリリースする場合）

1年以内に新しいコードがリリースされる場合、少なくとも9ヶ月は利用可能な最新のLTS、もしくはより新しい機能リリースを使うべきです。この「少なくとも9ヶ月は利用可能なLTSを使う」理由は、アプリケーションがサードパーティーコンポーネントに依存している場合、コンポーネント提供元のサードパーティーが、その9ヶ月という待ち期間で、LTSバージョンを完全にサポートすることを確認するための時間的猶予が得られるからです。LTSリリースが9ヶ月以上利用可能で、依存関係がまだサポートするように更新されていない場合、該当する依存関係を、より活発に保守されている代替の依存関係に置き換えることを検討してください。

If your application is being actively updated, with new features being tested and added
（アプリケーションが活発に更新され、新機能がテストされ、追加されている場合）

アプリケーションが活発に更新され、新機能がテストされ、追加されている場合、LTSがリリースされてから2年以内に新しいLTSに移行することを検討してください。開発者がまだアプリケーションに取り組んでいる場合、アプリケーションの全体的なメンテナンスの一環として、移行要件をテストし、対応できます。アクティブなアップデートが停止し、「変更を加えず、そのまま実行し続ける」状態になる前に、アプリケーションが最新のLTSになっていることを確認することで、やはり、サポートが終了するまでのLTSに依存できる期間を最大限に延ばすことができます。

If your application is running but not actively being changed
（アプリケーションは稼働しているが、積極的に変更されていない場合）

アプリケーションは稼働しているが、積極的な変更はなされていない場合、以下の場合を除き、すでに使用している機能リリースのままにしておくべきでしょう。

• 利用中のJDKバージョンのEoSLが残り1年未満に迫っている
• アプリケーションが、JDKバージョンよりも前にサポート終了を迎えるツールやサードパーティライブラリに依存している
• アプリケーションがメモリやCPUの使用率が高すぎる

「安定した」アプリケーションのアップグレードは、状況ゆえに正当化されるものである場合に考慮されるべきオプションです。アップグレードすることでパフォーマンス上のメリットを得たり、アプリケーションのサポート寿命を延ばしたり、あるいはJavaの驚異的な安定性を利用して、アップグレードを実行しようとしていたリソースを新しいアプリケーションの開発に使うこともできます。

Conclusion

JDKを常に最新の状態に保ち、ここで紹介したガイドラインに従うことで、安定性、セキュリティ、起動、ウォームアップ、スループット、リソース使用におけるたゆまぬ改善といった、Javaのすべての利点を最大限に活用できます。Java SE Subscriber、またはOracle Cloud Infrastructureを使用していて、Java Runtimeの更新またはアップグレードに関するハンズオン・サポートをご希望の場合は、My Oracle Supportでサービス・リクエストを提出してください。

• Java
• Technology