掲載内容は私個人の見解であり、所属する組織の公式見解ではありません。
今年(2025年)でJavaはサンマイクロシステムズ社が最初のベータ版をリリースしてから30周年を迎えました。サンマイクロシステムズ社をOracle社が買収した後は、Oracle社がJavaの発展をけん引してきました。
10年ほど前はOracleが公開するJDKを利用するのが一般的でしたが、現在では数種のJDKディストリビューションが存在し、Red Hat OpenJDK、Amazon Corretto、Eclipse Temurinなどが登場しています。とうとうMicrosoftが2021年にMicrosoft Build of OpenJDKを公開し、富士通もOpenJDKをベースとした富士通OpenJDKを製品で提供しています。しかし、依然としてOracleの動向がJava SEに与える影響は非常に大きく、Java SEの今後の動向を知るにはOracle Java SEの動向を注視する必要があります。
以下のOracle社のブログで、「In Java 24, of the 2,463 JIRA issues marked as fixed, 1,657 were completed by Oracle, while 806 were contributed by other members of the Java community.」と記載されており、図を見ていただくとOracle社の貢献度がまだまだ圧倒的に多いことはお判りいただけると思います。
https://blogs.oracle.com/java/post/the-arrival-of-java-24
Oracle社が公開しているOracle Java SE Supportのロードマップで、2014年3月に登場したOracle Java SEの8のサポート期限（Extended Support期限）が以前は2025年3月でしたが、長期サポートを望む顧客からの要望もあったようで2030年12月に延長されています。
公開されてから11年が経過されても社会システムを支え続けるJava SE 8の存在価値は非常に高いですが、とうとう2030年12月にOracle社のサポートが終了します。
Oracle社のサポートが終了しても各ディストリビューションは各々のサポートポリシーに則りサポートされますが、市場全体のJava SE 8への貢献度(セキュリティ修正を含む修正作業など)は下がることは容易に想像ができます。
2030年まで約5年の期間がありますが、Java SE 8が公開されてから11年も経過しており、Java SEも多くの新機能が追加されているだけで無く、削除されたAPIなどもあり、移行にはアプリケーションの改修が必要となる可能性が高く、Java SE 8を移行する影響（移行費用）が気になる時期ではないでしょうか？
Java SE 8サポート終了に向けた動き
すでにOracleはOracle Java SE 8においてもOracle JDK 8u211（2019年4月以降）から個人、開発、その他のユーザーのみ無償利用を可能とするライセンスで公開するなどサポート範囲を狭めており、サポート終了に向けた準備が始まっています。
ライセンスに関してはOracle Java SEライセンスに関するFAQの「現在利用可能なOracle Java SEリリースのライセンスにはどのようなものがありますか？」を参照ください。
Eclipse Foundationが公開する2024 Jakarta EE Developer Survey ReportではJava 8の使用率が2023年の61%から2024年に55%に減少したのに対し、Java 17の使用率が2023年の37%から2024年に56%に増加し、Java SE 8以降のバージョンが初めてJava SE 8を逆転したとされています。
Java SE 8からの移行ポイント
Java SE 8からの移行を考える場合のポイントを考えてみます。
Java SE 8からどのバージョンのJava SEに移行するか？
Oracle Java SE Supportのロードマップで「Extended Support期限」がJava SE 8より長く、業務システムでは長期サポートが元られるためLTS（Long Term Support）のバージョンを選択するのが自然です。
この場合、「11」もしくは「21以降のLTS版」を選ぶのが得策ということになります。
ちなみに2021年に17 (LTS)が公開される際のブログで、今後は2年サイクルでLTS（Long Term Support）のバージョンアップを行うことが提案され、現在は6ヶ月単位にフィーチャーリリースが公開されて2年サイクルでLTS版が公開されています。
LTS版は8年間サポートされているため、今後は約8年ごとにJava SEのバージョンアップを考えることが求められることになります。
JavaはJava 7からJava 9に、Project Coin、Project Lambda、Project Jigsawという3つの大きなプロジェクトの修正を取り込んでおり、大規模な修正であったため、これらの修正の取り込み時期の延期などもありJavaの公開が不定期であったとしています。ちなみにProject Coinは文法を使いやすくするもの、Project Lambdaはラムダ式の対応、Project Jigsawはモジュール化の仕組みの導入をするプロジェクトです。Java 9でこれらの修正が完了したこともあり、今後は定期的なサイクルで新バージョンを公開する方針としたようです。
非互換はどの程度あるか？
変更点は以下の各バージョンでの変更点を確認する必要があります。
https://openjdk.org/projects/jdk9/
https://openjdk.org/projects/jdk/10/
...
https://openjdk.org/projects/jdk/21/
技術者が一番気にする非互換としては、以前は利用することができたAPIが利用できなくなるようなアプリケーションの修正が必要となる非互換だと思います。
我々の周囲でも影響があると聞くのは以下のJEP320の修正による非互換です。
JEP 320: Remove the Java EE and CORBA Modules
Java EEに含まれるWebサービス関連やCORBA関連のモジュールを削除したというものです。
WebサービスやCORBAは元々サーバー向けの機能であるため、Java SE利用者にはあまり影響がなくJakarta EE利用者には、Jakarta EE製品が削除されたモジュールを提供しているはずなので影響は小さいと思います。
ただ、JAXBについてはXMLファイルの解析に使っていたアプリケーションもありそうです。私もJAXBを知った時には、XMLファイルを簡単にJavaオブジェクトとして扱えるため非常に便利だと感じ、Java SE上でJAXBを利用した経験があります。
それ以外にはJava SE 17で以下でSecurity Managerの廃止に向けた非推奨化が行われています。
JEP 411: Deprecate the Security Manager for Removal
Java SE 24では以下で完全に無効化されたため、Security Managerを利用しないように対処しておくのが良いでしょう。
JEP 486: Permanently Disable the Security Manager
周辺技術
Java SE 11 (LTS)もしくは21 (LTS)を利用する場合、それに対応したフレームワークや周辺機能に入れ替える必要があります。
Jakarta EE 10であればJava SE 11(以上)が必要ですし、Spring Boot 3.5.7 には少なくとも Java 17 が必要です。
使用しているJDBCドライバも対応するJDKのバージョンが示されている場合が多いです。例えばOracle JDBCドライバであれば、Oracle Database JDBC driver and Companion Jars Downloadsに記載されています。
Oracle Software テクニカル・サポート・ポリシー ～変更履歴～には以下のように記載されています。Java SE 8のサポート終了と共に利用できなくなる周辺技術があるため、Java SE 8からの移行と共に周辺技術の移行の検討も必要です。
「Java 8 の Extended Support は 2030 年 12 月に終了し、それ以降は Oracle Database 19c においてJava のアップデートの提供を受けられなくなります。」
新機能は？
Java 11から起動時間が短縮されたと言われており、Java 21からZGCがデフォルトで有効となり、性能改善は大いに期待できると思います。
Java 11では低遅延とスケーラビリティの両立を目的として設計されたZGCが実験的にJEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)で追加され、Java 15のJEP 377: ZGC: A Scalable Low-Latency Garbage Collector(JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production))で正式に利用可能となりました。
更にJava 21(JEP 439)で世代別ZGC（Generational ZGC）が登場しました。
移行とは関係ありませんが、個人的にはJava 21からプレビュー版として登場した以下のJEP 445がいつ正式版になるか気になっています。
JEP 445: Unnamed Classes and Instance Main Methods(https://openjdk.org/jeps/445)
スクリプト言語と比べて、Javaは簡単な処理を実行したいだけなのに、おまじないのように記載が必要なことが多くて煩わしいとよく言われてきましたが、JEP 445が正式版になるとかなり記述は減ると思いますが、逆に我々が若いころに教わったJavaの常識が覆されるという意味でも注目しています。興味がある方はどんな修正か調べてみてください。