Java 8/11/17/21の違いと選び方｜LTS・移行の要点整理

まずJavaは「どのバージョンを使うべきか」で迷いやすい言語です。

しかし現場でよく見かけるJava 8/11/17、そして最新LTSのJava 21は、機能だけでなくサポートや周辺エコシステムで選び方が変わります。

そのため本記事では、JDK/JREの基本から、番号の読み方、LTSの意味、実務での選定と移行ポイントまでを、8/11/17/21を軸に整理します。

つまり読み終えると「今の自分（新規開発／既存移行）ならどれを選ぶべきか」と「移行時にどこで詰まりやすいか」を短時間で把握できます。

まず押さえる：Java/JDK/JREの違い

まずバージョンの話に入る前に、混同しやすいJava（言語/プラットフォーム）・JDK・JREの関係を整理します。

さらに現場の会話で「Javaのバージョン」と言う場合、多くはJDKのバージョンを指します。

そのため選定の起点は「どのJDKを基準に開発・実行するか」です。

まずJDK（Java Development Kit）は開発者向けの一式です。

つまりコンパイラ（javac）やデバッガ、各種ツールと実行環境を含みます。

そのためアプリをビルドしたり、テストしたり、CIで動かしたりする側は基本的にJDKを入れます。

一方でJRE（Java Runtime Environment）は実行専用の構成として語られてきました。

しかし近年は配布形態の変化もあり、JDKを入れて実行するのが一般的です。

したがって実務ではJREかJDKかで迷うより、まず「基準JDKバージョン」を決めるのが重要です。

Javaのバージョン番号の読み方（1.8と8、SE/EEなど）

まず「Java 1.8＝Java 8」問題や、Java SE/EEの違いなど、名称・番号体系の混乱ポイントを解消します。

まずJava 8が「1.8」と表記されることがあるのは、昔の命名が「Java 1.x」系列だった名残です。

そのため設定ファイルやライブラリ要件に「1.8」と書いてあっても、基本的にはJava 8と同じだと考えて問題ありません。

一方でJava 9以降は表記がすっきりし、Java 11、Java 17のようにメジャー番号で呼ぶのが標準になりました。

しかし実務では、ビルドツールが使う表現が複数ある点で混乱が起きます。

例えば「ソースの文法レベル」「バイトコードのターゲット」「実行するJDK」の3つがズレると、ビルドは通るのに実行時に落ちる事故が起こります。

さらにJava SEは標準版で、業務アプリの多くはここに含まれるAPIとJVMの上で動きます。

一方でJava EEは企業向け仕様群でしたが、現在はJakarta EEに移行しています。

そのため移行やバージョンアップの文脈では、EE由来APIを使っているかを意識すると整理が速くなります。

リリースサイクルとLTS（Long Term Support）の考え方

まず半年ごとのリリースとLTSの位置づけを理解すると、実務で特定バージョンに収束しやすい理由が見えます。

まずJavaは6か月ごとに新バージョンが出るモデルを採用しています。

例えばOpenJDKは、FEATURE番号が6か月ごとに進むことを明確にしています。

そのためリリースは概ね3月と9月に来る前提で、計画が立てやすい一方、追従コストも発生します。JEP 322（Time-Based Release Versioning）

しかし業務システムは、半年ごとに依存ライブラリや運用手順を総点検するのが現実的ではありません。

そのため多くの組織はLTSを基準に、数年単位の追従計画を作ります。

一方で「LTSかどうか」はJavaそのものの性質というより、使うJDKディストリビューションのサポート方針に強く依存します。

例えばOracleのロードマップでは、8/11/17/21/25がLTSとされています。

さらに今後は2年ごとにLTSを提供する予定も示されています。Java SE Supportロードマップ（Oracle）

したがって非LTSは「悪い」ではなく、組織の追従力と自動テストの厚みが焦点です。

例えば小規模でCIが強いチームなら非LTSを試す価値があります。

一方で長期運用や多人数開発では、情報量と実績が蓄積しやすいLTSが安全になりやすいです。

実務で選択肢になりやすいJavaバージョン一覧（8/11/17/21）

まず現場で候補に上がりやすいJava 8/11/17/21について、特徴・採用背景・向くケースを俯瞰します。

まず8/11/17/21はいずれもLTSとして語られやすく、実務の標準候補になりやすいラインです。

しかし選定は機能差だけで決まりません。

例えば依存ライブラリ対応、監視/APM、社内ビルド基盤、コンテナ基盤の対応がボトルネックになりがちです。

そのため現実のプロジェクトでは「今すぐ最適」より「将来の更新がしやすい」ことが重要になります。

例えば短期的にJava 8で動いても、周辺が8を切ると数年後に移行が重くなります。

一方で最新LTSが魅力的でも、依存が追いつかないなら無理に上げない方が安全です。

Java 8の特徴とよくある採用理由

まずJava 8はラムダ式やStream API、新しい日時API（java.time）などを導入し、現代的なJavaの起点になりました。

さらにOptionalも含め、Nullや日時処理の事故を減らす土台が整いました。

しかしJava 8が現場に残り続ける理由は、技術的優位というより運用上の合理性です。

例えば基幹系では、動いているものを変えるリスクが高く、再認証や検証が高コストになります。

そのため古いミドルウェアや社内標準が8固定だと、上げたくても上げられません。

一方で新規開発でJava 8を選ぶのは、基本的に避けたい判断です。

そのため新規は後述の17/21を基準にし、どうしても8が必須なら「更新計画」を別途用意します。

Java 11の特徴と移行メリット

まずJava 11は新リリースモデル移行後の最初のLTSとして、8の次の着地点になりやすいバージョンでした。

そのため現場でも「まず11まで上げた」という履歴があるシステムをよく見かけます。

さらに8→11のメリットは機能追加だけではありません。

例えば9以降の変更点を一度越えられるため、以降のLTS（17/21）へ段階的に上げる道筋が作りやすくなります。

しかし今から新規で11を選ぶ動機は弱くなっています。

そのため既存が8で止まっている場合に、11を「中継点」として使うのが実務的です。

Java 17の特徴と現在の標準候補

まずJava 17は、実務での標準候補になりやすいLTSです。

さらにフレームワークやツールが「まず17をサポートする」形に揃いやすく、採用時の不確定要素が減ります。

そのため迷ったら17と言われやすいのは、機能と実績、周辺対応のバランスが良いからです。

例えばrecordsやtext blocks、switch式、pattern matchingなどは、日常の実装に効きます。

そのためDTOの記述量が減り、SQL/JSONの可読性が上がり、条件分岐の重複も減ります。

さらに運用面ではJVMやGCの改善が積み重なり、安定性やチューニングの選択肢が増えています。

そのためクラウドでは起動時間やメモリ制約がコストに直結し、古いバージョンを使い続けると損が大きくなります。

Java 21の特徴と採用判断ポイント

まずJava 21は最新LTSとして、最新改善を取り込みつつ長期運用のベースにしやすいのが魅力です。

さらにOpenJDKの一次情報として、JDK 21は2023年9月19日にGAに到達しています。

そのため「これから長く使う」前提なら候補に上がりやすいです。JDK 21（OpenJDKプロジェクト）

しかし採用判断は「良さ」より「追従力」で決めるのが現実的です。

例えば依存ライブラリが21を正式サポートしているか、社内のビルド基盤が追随できるかが重要です。

そのため最新LTSは、事例が増えるまでの時間差も見込んで進めます。

なおOracle JDK 21については、更新提供のライセンス条件が将来切り替わる旨がリリースノートに明記されています。

そのため「どのディストリビューションを使うか」と「いつまで無償更新が必要か」をセットで決めるのが安全です。JDK 21 リリースノート（Oracle）

例えば現実的な運用パターンとして、開発の基準を17に置きつつ、CIで21でもビルドとテストを回す方法があります。

そのため21への移行準備を進めながら、本番適用のタイミングは周辺対応や実績を見て決められます。

機能の違い：言語機能の主な変化（ラムダ〜recordsまで）

まず開発体験に直結する言語機能は、バージョン差を実感しやすいポイントです。

さらに新機能は「短く書ける」だけでなく、「誤りを起こしにくい表現」を増やす方向に進化しています。

そのためチーム開発では保守性とレビュー効率が変わります。

まずJava 8の大きな節目はラムダ式とStream APIです。

そのためコレクション処理を宣言的に書けて、ループのバグや一時変数の乱立が減りました。

一方でJava 11ではvar（ローカル変数の型推論）が入り、型名の重複を減らせます。

しかし型が見えなくなることでレビューが難しくなる場面もあります。

そのためプロジェクト規約で使いどころを決めるのが実務的です。

さらにJava 17前後ではtext blocksやrecords、switch式、pattern matchingなどが揃い、日常の実装で効きます。

そのためDTOのボイラープレートが減り、SQL/JSONの可読性も上がります。

機能の違い：JVM・GCの主な変化

まず同じコードでも、JVMやGCの進化で性能・レイテンシ・運用性が変わります。

さらに差が出やすいのはベンチマークより運用時です。

例えばピーク時のレイテンシ、コンテナ環境でのメモリ制御、障害調査のしやすさが改善されてきました。

一方でGCは停止時間（STW）やスループット特性が設定で変わり、選択肢が増えるほどチューニング余地が出ます。

そのため古いバージョンに留まると「設定で逃がす」余地が減り、最終的にインフラ増強でコストを払う形になりがちです。

さらに障害対応では「再現できない」「情報が足りない」が最も高くつきます。

そのためダンプ取得やログ、監視ツールとの相性が良いバージョンを選ぶことが結果的に安く済みます。

互換性の違い（ソース互換・バイナリ互換・動作互換）

まず「コンパイルできるか」「ビルド済みJarが動くか」「実行時の挙動が同じか」は別問題です。

そのため互換性を3つに分けて理解します。

まずソース互換は、同じソースが新しいコンパイラでそのまま通るかです。

そのためCIでコンパイルを回せば比較的早く見つかります。

一方でバイナリ互換は、すでにコンパイル済みJarが新しいJVMで動くかです。

しかし古いライブラリがJDK内部APIに依存していると壊れやすいです。

そのため「昔から動いている社内ライブラリ」が落とし穴になりやすいので、依存の棚卸しが重要です。

さらに動作互換は最も厄介で、起動はするが挙動が微妙に変わるケースです。

例えば文字コード、TLS、反射、日時など、環境境界で差分が出やすいです。

したがって移行の成否は、動作確認をどれだけ自動化できるかに左右されます。

移行でハマりやすい変更点（削除・非推奨・モジュール化）

まずJava 9以降のモジュール化や、Java EE/CORBAなどの削除は移行トラブルの定番です。

そのため事前にチェックすべき論点をまとめます。

まず移行で大きな山になりやすいのは、文法差ではなく「消えたもの」「使い方が変わったもの」です。

例えばJPMSはJDK内部APIへのアクセスを厳しくし、古いライブラリが反射で内部に触ると起動時に落ちます。

一方で過去に同梱されていたAPIが削除され、依存関係を明示的に追加する必要も出ます。

そのためビルドログだけでなく、実行時エラー（ClassNotFound等）を丁寧に追う必要があります。

したがって実務での対策は、移行前に依存関係を可視化し、危険な依存を早めに洗い出すことです。

例えば古い社内共通ライブラリや、メンテされていない支援ツールは影響範囲が広がりがちです。

JDKディストリビューションの違い（Oracle/OpenJDK/Adoptiumなど）

まず同じ“Java 17”でも配布元によってライセンスやサポート、提供形態が異なります。

そのため実務での選び方の軸を整理します。

まずJDKは「仕様と実装（OpenJDK）」と「配布（ディストリビューション）」に分けると混乱が減ります。

例えば多くの配布はOpenJDKをベースにしていますが、パッチ提供方針やサポート条件が異なります。

さらに配布元の選定軸は、ライセンス、サポート期間、更新頻度、脆弱性対応体制、採用実績です。

例えばEclipse AdoptiumはTCK準拠のOpenJDKバイナリ提供を掲げています。Eclipse Adoptium

一方で開発環境と本番環境で配布元を変えると、再現性のない不具合を抱えやすいです。

そのため少なくとも同じメジャーバージョン、同じ更新ポリシーで揃えるとトラブルが減ります。

どのJavaバージョンを選ぶべきか（新規開発・既存移行）

まず目的（新規か移行か）と制約（サポート、依存、運用）で最適解は変わります。

そのため判断基準をチェックリスト的に提示します。

まず新規開発では、原則として最新LTSか、その一つ前のLTSが現実的です。

そのため周辺エコシステムの追随が十分で、チームが追従できるならJava 21が候補になります。

一方で迷う場合や、依存の対応が読み切れない場合はJava 17が堅い選択です。

一方で既存移行では、いきなり最終目的地に飛ぶより「移行の壁」を越える順序が重要です。

例えばJava 8から上げる場合は、依存棚卸し、ビルドツール更新、モジュール影響確認が効きます。

そのためケースによっては、8→11→17/21のように段階的に進めた方が、切り分けがしやすく総工数が下がります。

さらに判断のポイントは次の5つです。

• フレームワークの最低要件
• 依存ライブラリの対応状況
• 本番OSやコンテナ基盤の対応
• 運用監視やAPMの互換性
• 自動テストの厚み

そのためこれらが揃っていれば新しいLTSへ上げやすく、揃っていなければ別の場所で詰まります。

したがってバージョン選びは技術選定というより、運用設計と品質戦略の一部として扱うのが成功しやすい進め方です。

まとめ：Javaバージョンの違いと選び方の要点

まずJavaのバージョンの違いは、言語機能だけでなく、サポートと周辺エコシステム、運用のしやすさに大きく出ます。

そのためJava 8は残りやすい一方で、新規採用は避けるのが基本です。

さらにJava 11は移行の中継点として価値があり、Java 17は現在の標準候補になりやすいバランス型です。

そしてJava 21は最新LTSとして、追従力がある組織ほどメリットを取り込みやすい選択肢です。

一方でLTSの理解が進むと、実務でLTSに収束する理由が見えてきます。

例えばOpenJDKは6か月サイクルのモデルを明示し、OracleはLTSの扱いをロードマップで示しています。

したがって移行は「コンパイルが通ったら終わり」ではありません。

つまりソース互換・バイナリ互換・動作互換を分けて、実行時の挙動と運用まで含めて計画することが重要です。

さらに同じJava 17でも配布元で条件が変わるため、JDKディストリビューションは必ずセットで選びます。

そのため新規は17か21、移行は依存と検証体力に合わせて段階的に進める方針で考えると、現実的な意思決定ができます。

また関連記事として、Javaの学習やキャリア設計を進めたい方は次も参考になります。

• エンジニアがJavaで成長するためのステップアップ戦略
• エンジニアとは？仕事内容・種類・キャリアをわかりやすく解説