--- title: "Java 27とは｜非LTSの半年運用とG1・オブジェクトヘッダ既定化の影響" url: "https://www.issoh.co.jp/tech/details/17712/" published: 2026-09-20 updated: 2026-10-11 categories: ["Java"] publisher: "株式会社一創" --- # Java 27とは｜非LTSの半年運用とG1・オブジェクトヘッダ既定化の影響 Java 27（JDK 27）は2026年9月15日にGA（一般提供）へ到達しました。入った変更は9本のJEPで、そのうちコードを書き換えなくても挙動が変わるのは、G1をすべての環境の既定GCにするJEP 523と、オブジェクトヘッダを既定でコンパクト形式にするJEP 534の2つです。残りはTLS 1.3の耐量子ハイブリッド鍵交換、JFRの値マスク、4本のプレビューと1本のインキュベータです。既定値として何が変わり、非LTSが更新運用にどう効き、27へ載せるかどうかをどの条件で決めるのかを、OpenJDKとOracleの公開情報で整理します。 ## まとめ：Java 27を入れる案件と25で止める案件の分かれ目 結論から書きます。Java 27は非LTSの機能リリースで、OracleのPremier Supportは2027年3月で切れます。次のLTSは2027年9月のJava 29です。半年ごとにJDKを差し替えて再検証できる体制がある案件だけが27の対象で、それ以外はLTSである25に留めるのが安全側の線になります。 27で実務に効くのは、機能追加より既定値の変更です。1CPU以下または物理メモリ1792MB未満という小さな実行環境で自動的にSerial GCが選ばれていた挙動がなくなり、G1に統一されました。オブジェクトヘッダも64ビット幅が既定になり、ヒープ使用量とGC回数が下がる代わりに、ヘッダのビット配置に依存するツールやエージェントは影響を受けます。コードを1行も変えなくても本番の数字が動く変更です。 セキュリティ側では、TLS 1.3のハイブリッド鍵交換X25519MLKEM768が既定で有効になりました。中間装置が未知のグループを弾く構成では接続の再検証が要ります。更新の受け取り方も変わり、四半期のCPUに加えて月次のCSPUが走るようになりました。パッチ適用を3か月間隔で組んだ運用は見直しの対象です。 ## Java 27で確定した9つのJEPと非LTSという位置づけの整理 プレビューとインキュベータは本番で既定有効にならないため、既定挙動として効く変更とは分けて数えます。 ### 2026年9月15日のGAで入った9つのJEPと4つのプレビュー機能 [OpenJDKのJDK 27プロジェクトページ](https://openjdk.org/projects/jdk/27/)によると、27は2026年6月4日にRampdown Phase Oneでメインラインから分岐し、7月16日にPhase Two、8月6日にRelease Candidate Phase、8月20日にRC Buildを経て、9月15日にGAへ到達しました。含まれるJEPは9本です。 | JEP | 内容 | 状態 | | --- | -------------------- | ---------- | | 523 | G1を全環境の既定GCに | 正式 | | 527 | TLS 1.3の耐量子ハイブリッド鍵交換 | 正式 | | 534 | コンパクトオブジェクトヘッダを既定に | 正式 | | 536 | JFRのインプロセスデータ秘匿 | 正式 | | 531 | 遅延定数 | 第3プレビュー | | 532 | switch等のプリミティブ型対応 | 第5プレビュー | | 533 | 構造化並行処理 | 第7プレビュー | | 538 | 暗号オブジェクトのPEM符号化 | 第3プレビュー | | 537 | Vector API | 第12インキュベータ | 正式機能は4本だけで、言語仕様の追加はプレビューに寄りました。パターンマッチングのプリミティブ型対応も構造化並行処理も `--enable-preview` なしでは使えません。JDKとJRE、JVMの役割分担があいまいなまま版だけ追うと判断を誤るため、用語の土台は[Java SEとJDK・JRE・JVMの違いを整理した記事](https://www.issoh.co.jp/column/details/3113/)で先に揃えてください。 ### 非LTS版のPremier Supportは2027年3月まで [Oracle Java SE Supportのロードマップ](https://www.oracle.com/java/technologies/java-se-support-roadmap.html)は、27を非LTSとして扱い、GAが2026年9月、Premier Supportの終了が2027年3月、Extended Supportは「Not Available」と記載しています。LTSは8・11・17・21・25の5世代で、次のLTSは2027年9月のJava 29です。 非LTSの扱い方には注意点があります。Oracleは非LTSを「直近のLTSに対する実装上の改良の累積」と位置づけ、次の機能リリースが出た時点で前の非LTSはsupersededになると明記しました。28が2027年3月に出れば、27向けの更新はそこで止まる建て付けです。版を固定して2年動かす前提のシステムに27を載せると、セキュリティ更新の受け取り口を半年で失います。 逆に、半年ごとに載せ替える運用が成立しているなら29へ上がるときの差分は小さくなります。25から29へ一気に飛べば4世代ぶんの変更をまとめて浴びるため、27・28を踏み台にする選択には筋があります。 ## G1既定化とコンパクトオブジェクトヘッダ既定化で変わる実行時の挙動 本番の数字が動く変更はこの2つに集中しています。コマンドラインで明示指定していない環境ほど影響が大きくなります。 ### 1CPU・1792MB未満でSerialが選ばれていた環境の切り替わり [JEP 523](https://openjdk.org/jeps/523)は、GCの自動選択ルールを一本化しました。JDK 9以降、サーバー環境ではG1が既定でしたが、利用可能なCPUが1個以下、または物理メモリが1792MB未満の「制約環境」ではSerial GCが選ばれていました。27では、プロセッサ数とメモリサイズにかかわらずG1が選ばれます。 この条件に該当しやすいのは、メモリ制限を1GiBや1.5GiBで切ったコンテナ、CPU割り当てが1未満のサーバーレス実行環境、小型の常駐バッチです。JEPの本文は、G1が同期処理の削減で最大スループットをSerial並に、インクリメンタル回収で最大レイテンシをSerial以上に改善し、ネイティブメモリ使用量もSerial程度まで落としたと説明しています。それでもSerialが向く処理は残るため、選択肢が消えたわけではありません。`-XX:+UseSerialGC` を明示すれば従来どおり動きます。 小さなコンテナでJVMのネイティブメモリ使用量が増え、Pod単位の上限に触るケースを先に疑ってください。ヒープ設定だけを見ていると原因にたどり着けません。 ### オブジェクトヘッダ96ビットから64ビットへ・ヒープ22%削減の実測 [JEP 534](https://openjdk.org/jeps/534)は、64ビットアーキテクチャにおけるHotSpotのオブジェクトヘッダを96ビットから64ビットへ縮め、その形式を既定にしました。JEPが挙げる効果は、SPECjbb2015でヒープ使用量22%削減・CPU時間8%削減、G1とParallel GCでGC実行回数15%削減、並列JSONパーサで実行時間10%短縮です。オブジェクトを大量に抱えるアプリケーションほど効きます。 非互換のリスクはヘッダのビットを直接読むコードにあります。JVMTIエージェント、ヒープダンプを独自解析するツール、Unsafeでヘッダのオフセットを前提にしたライブラリが該当します。将来の拡張でビットが追加される可能性もJEPに書かれており、Project Valhalla向けに4ビットが予約済みです。旧来の96ビット形式に廃止予定はないため、問題が出たら `-XX:-UseCompactObjectHeaders` で戻せます。 ### 2つの既定値の変更を本番投入の前に確かめるコマンドと戻し方の手順 既定値が変わったかどうかは、アプリケーションを動かす前にJVMへ聞けば分かります。実行中のフラグ値を出力して、G1とコンパクトヘッダの状態を確認します。 ``` $ java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|UseSerialGC|UseCompactObjectHeaders" bool UseCompactObjectHeaders = true {product} {default} bool UseG1GC = true {product} {ergonomic} bool UseSerialGC = false {product} {default} ``` 末尾の `{ergonomic}` は「JVMが自動で決めた」印、`{default}` は「既定のまま」、`{command line}` は「起動オプションで指定した」印です。ここを読むと、27に上げたことで自動選択が変わったのか、元から明示していたのかを区別できます。切り戻しは起動オプションの追加だけで済みます。 ``` $ java -XX:+UseSerialGC -XX:-UseCompactObjectHeaders -jar app.jar ``` コンテナで動かす案件では、メモリ上限を1792MB未満に設定した環境だけを抜き出して先に流すと、切り替わりの影響を最小の手数で拾えます。 ## TLS 1.3の耐量子ハイブリッド鍵交換で確認する接続側の影響範囲 アプリケーションのコードは変えずにハンドシェイクの中身が変わるため、確認対象は自分のコードではなく相手側と経路上の装置になります。 ### X25519MLKEM768が既定の先頭・SecP系は既定で無効 [JEP 527](https://openjdk.org/jeps/527)が実装したハイブリッドスキームは3つです。X25519とML-KEM-768を組み合わせたX25519MLKEM768、secp256r1とML-KEM-768のSecP256r1MLKEM768、secp384r1とML-KEM-1024のSecP384r1MLKEM1024。このうち既定で有効なのはX25519MLKEM768のみで、鍵交換スキーム一覧の先頭に置かれます。SecP系の2つは既定で無効です。 ハイブリッドという名のとおり、従来の楕円曲線鍵交換と格子ベースの鍵カプセル化を併用します。片方が破られてももう片方が残る設計で、既存コードを変えずにハンドシェイクの安全性が上がる仕組みです。相手が対応していなければ通常のスキームへ交渉が落ちます。 問題が出るのは、ClientHelloのサイズやkey\_shareの内容に敏感な中間装置がある構成です。ML-KEM-768の公開鍵は従来の楕円曲線より桁違いに大きく、初期パケットが膨らみます。古いTLS終端装置やインスペクション機器を挟む社内網では、27へ上げた直後にハンドシェイク失敗が出る余地があります。 ### jdk.tls.namedGroupsで鍵交換の並びを固定する設定例 使う鍵交換スキームは、システムプロパティ `jdk.tls.namedGroups` で明示できます。優先順は記述順です。切り分けのときは、ハイブリッドを外した並びと入れた並びを比べます。 ``` $ java -Djdk.tls.namedGroups=x25519,secp256r1,secp384r1 -jar app.jar $ java -Djdk.tls.namedGroups=X25519MLKEM768,x25519,secp256r1 -jar app.jar ``` 接続単位で切り替えるなら、`SSLParameters` のsetNamedGroupsを使います。全体の既定は触らず、問題のある宛先だけ従来のスキームに寄せる形が扱いやすい構成です。 ``` SSLContext ctx = SSLContext.getDefault(); SSLParameters params = ctx.getDefaultSSLParameters(); params.setNamedGroups(new String[] { "x25519", "secp256r1" }); SSLSocketFactory factory = ctx.getSocketFactory(); SSLSocket socket = (SSLSocket) factory.createSocket("legacy.example.jp", 443); socket.setSSLParameters(params); socket.startHandshake(); ``` 切り分けは `-Djavax.net.debug=ssl:handshake` でログを出し、supported\_groupsに何が並んだかを見る順が早道です。宛先ごとに上の2通りを比べれば、原因がハイブリッド鍵交換なのか経路側なのかが1回で分かります。 ## JFRのデータ秘匿とプレビュー機能を本番環境へ出す前の切り分け 記録ファイルの安全性を上げる変更は既定で効き、次のLTSを見据えて触るプレビューは明示的に有効化したときだけ動きます。 ### redact-keyとredact-argumentで消える値と残る値 [JEP 536](https://openjdk.org/jeps/536)は、JDK Flight Recorderが記録ファイルへ書き出す前に、コマンドライン引数・環境変数・システムプロパティの値をマスクする仕組みを入れました。既定のフィルタはパスワードやトークンを含むキー名のパターンを12種類持ち、該当する値は `[REDACTED]` に置き換わります。障害解析のためにJFRの記録を社外へ渡す運用では、渡す前の手作業が1つ減る変更です。 既定のまま起動すると、キーストアのパスワードは記録に残りません。 ``` $ java -XX:StartFlightRecording:filename=dump.jfr \ -Djavax.net.ssl.keyStorePassword=SECRET_PASSWORD -jar app.jar ``` 社内独自のキー名を足すなら `redact-key`、引数のパターンを足すなら `redact-argument` を指定します。何がマスク対象になったかは `-Xlog:jfr+redact=debug` で確認できます。 ``` $ java -XX:FlightRecorderOptions:'redact-key=confidential,redact-argument=-*apikey *' \ -Xlog:jfr+redact=debug -XX:StartFlightRecording:filename=dump.jfr -jar app.jar ``` マスクの対象はキーと値の組と引数に限られます。アプリケーションが自分でログに書いた文字列や独自イベントのフィールドは対象外で、そちらは従来どおりコード側で伏せてください。 ### –enable-previewで触る構造化並行処理のAPI変更点 [JEP 533](https://openjdk.org/jeps/533)で、構造化並行処理は第7プレビューになりました。`java.util.concurrent` の `StructuredTaskScope` を使い、複数のサブタスクを1つのスコープに閉じ込めて、失敗と取り消しをまとめて扱う書き方です。 ``` Response handle() throws ExecutionException, InterruptedException { try (var scope = StructuredTaskScope.open()) { Subtask user = scope.fork(() -> findUser()); Subtask order = scope.fork(() -> fetchOrder()); scope.join(); return new Response(user.get(), order.get()); } } ``` 25・26から変わった点が複数あります。型パラメータに例外型が加わって `StructuredTaskScope` になり、`open()` がUnaryOperatorでスコープ設定を受け取れるようになりました。Joinerには `allSuccessfulOrThrow()`・`anySuccessfulOrThrow()`・`awaitAllSuccessfulOrThrow()`・`allUntil(Predicate)` があり、`awaitAll()` は削除、タイムアウトは `onTimeout()` から `timeout()` へ置き換わりました。25で書いたプレビューコードはそのままでは通りません。 コンパイルと実行の両方で `--enable-preview` が要ります。プレビューAPIはクラスファイルに版が刻まれるため、27でビルドしたクラスは28以降のJVMで動きません。モジュール境界と合わせて置き場所を決めると後で剥がしやすくなります。境界の切り方は[Javaモジュールシステムとmodule-info.javaの書き方](https://www.issoh.co.jp/tech/details/3253/)にまとめています。 ``` $ javac --release 27 --enable-preview -d out src/Main.java $ java --enable-preview -cp out Main ``` ## サポート期限とパッチ提供間隔から見たJava 27の運用コスト 版を上げる判断は、機能の魅力より更新の受け取り方で決まります。27の前後では、パッチ提供のリズムとライセンス条件が同時に動きました。 ### CPUとCSPUで毎月どちらかが出る2027年までの更新日程 [Oracleのセキュリティアラート一覧](https://www.oracle.com/security-alerts/)によると、四半期ごとの累積パッチであるCritical Patch Update（CPU）は1月・4月・7月・10月の第3火曜に出ます。直近は2026年10月20日、次は2027年1月19日、4月20日、7月20日です。 これに加えて、2026年5月28日からCritical Security Patch Update（CSPU）が始まりました。CSPUは2月・3月・5月・6月・8月・9月・11月・12月の第3火曜に出る、対象を絞った小さめの更新です。2026年11月17日、12月15日、2027年2月16日、3月16日が予定されています。CPUとCSPUを合わせると、毎月どちらかが出る計算になります。 3か月に一度まとめて検証して当てる現場では、この変更のほうがJEPより影響が大きくなります。全部を毎月当てるか、CSPUは内容を見て取捨するかを先に決めてください。なお、Oracle製品全体ではCSPUが毎月の枠で出ますが、Java向けの修正が実際に入った月は限られます。2026年8月に出た21.0.12.1などの版と、4桁目の版番号の判定方法は[Oracle CSPUとJavaの月次パッチを整理した記事](https://www.issoh.co.jp/tech/details/18268/)にまとめています。 ### Oracle JDK 21は2026年10月のCPUからOTNライセンスへ 同じロードマップに、ライセンス条件の変更も書かれています。Oracle JDK 21は2026年10月のCPU以降のアップデートから、Java SE OTNライセンス（Oracle Technology Network License Agreement for Java SE）で提供される予定です。これは8・11・17のアップデートに適用されているものと同じライセンスで、個人利用と開発用途は無償ですが、本番利用の条件が変わります。Oracle JDK 25も2028年9月以降のアップデートが同じ扱いになる計画です。 ここを外すと、27を検討する以前に足元の21環境が条件違反になりかねません。無償で使い続けるなら[jdk.java.netが配布するOpenJDKのGAビルド](https://jdk.java.net/27/)や各ディストリビューションのビルドへ切り替える判断が要ります。無償で使える範囲の線引きは[OpenJDKの商用利用とOracle JDKとの違いを整理した記事](https://www.issoh.co.jp/tech/details/10212/)で扱っています。 ## Java 27を採用する条件と25のまま据え置く場面の線引き ここからは判断です。技術的な良し悪しではなく、その案件の更新体制と検証コストで決めます。 ### Java 27を入れて良い案件の条件はプレビュー検証と短期更新 27を入れる条件は2つあり、両方を満たす案件に限ります。1つ目は、2027年3月に28へ載せ替える工数があらかじめ確保されていること。Premier Supportの終わりと28のGAが同じ時期に来るため、載せ替えを前提にしない採用は更新が止まる道です。2つ目は、CI上でJDKを差し替えて回帰テストを一晩で流せること。半年サイクルは、検証が手作業の現場には短すぎます。 この2つを満たしたうえで27が効くのは、オブジェクトを大量に抱えるサービスです。コンパクトオブジェクトヘッダの既定化だけでヒープが2割前後下がるなら、インスタンスサイズを1段落とせる可能性があります。数百台規模なら、載せ替え工数を上回る差になり得ます。 ### Java 25のまま据え置く案件と27を見送る5つの具体的条件 次の条件に1つでも当たるなら、27は見送って25に留めます。曖昧にせず、条件で切ってください。 - 顧客との契約でJDKの版を固定し、年単位で変更できない - JVMTIエージェント、APM、ヒープ解析ツールのいずれかが27未対応 - TLS終端やインスペクション装置を自社で更新できない経路を通る - Javaランタイムの更新にリリース判定の会議が要り、半年ごとに回せない - フレームワークやアプリケーションサーバーのサポート対象に27が入っていない 5つ目は見落としやすい条件です。フレームワーク側の対応表は、JDKのGAから数か月遅れることがあります。[Spring Boot 4.1系の依存関係と最小構成をまとめた記事](https://www.issoh.co.jp/tech/details/17478/)のように、使っている基盤の対応バージョンを先に確認してから、JDKの版を決める順番にしてください。順番を逆にすると、JDKだけ上げて動かない状態で止まります。 ### 受託開発でJava 27を前提に見積もるときの検証工数の見方 外部に開発や移行を委託する場合、27を前提にした見積もりで見るべきは機能開発の工数ではありません。既定値が変わった2点（GC選択とオブジェクトヘッダ）の性能再測定、TLS接続先の洗い出しと疎通確認、JFRやAPMの記録が従来どおり取れるかの確認、そして2027年3月の28載せ替えを含むかどうか。この4項目が見積もりに書かれているかで、非LTSの扱いを分かっている相手かどうかが判別できます。 既存システムのJDKを上げる工程を切り出して外へ出す場合は、[システムマイグレーション・リプレイスの相談窓口](https://www.issoh.co.jp/service/system/migration/)から、現行の版・依存ライブラリ・接続先の一覧を持ち込む形が話が早くなります。版を上げること自体より、上げた後の再検証の範囲をどこで区切るかが費用を決めます。 ## よくある質問 Java 27をめぐって実際に検索されている質問に、公開情報の範囲で答えます。 ### Java 27はLTSですか？ LTSではありません。Oracle Java SE Supportのロードマップは、LTSを8・11・17・21・25の5世代とし、27を非LTSの機能リリースとして扱っています。27のPremier Supportは2027年3月までで、Extended Supportの提供はありません。次のLTSは2027年9月に予定されているJava 29です。 ### Java 25からJava 27に上げるとコードの修正は必要ですか？ 正式機能の4本はコードの書き換えを求めません。ただし25でプレビューAPIを使っていた場合は別です。構造化並行処理は第7プレビューで型パラメータとJoinerの構成が変わり、awaitAll()は削除、onTimeout()はtimeout()へ置き換わりました。プレビューを本番に入れていないなら、作業の中心は再検証です。 ### G1が既定になると小さいコンテナでメモリは増えますか？ JEP 523は、G1のネイティブメモリ使用量をSerial程度まで下げたと説明しています。ただし、これまで自動でSerialが選ばれていた1CPU以下・物理メモリ1792MB未満の環境では、GCの実装そのものが入れ替わります。メモリ上限を厳しく切ったコンテナでは、切り替え前後の実測を取ってから本番へ出してください。 ### 耐量子ハイブリッド鍵交換は既存のTLS接続を壊しませんか？ 相手が対応していなければ従来の鍵交換へ交渉が落ちるため、通常の経路では接続が維持されます。注意すべきは、ClientHelloが大きくなることに耐えられない中間装置がある場合です。切り分けには `-Djdk.tls.namedGroups` でハイブリッドを外した並びを試し、差が出るかを見ます。宛先単位で調整するなら、SSLParametersのsetNamedGroupsで接続ごとに指定できます。 ### Java 27はいつまで更新が出ますか？ Oracleは非LTSを「直近のLTSに対する改良の累積」と位置づけ、次の機能リリースが出た時点で前の非LTSはsupersededになると明記しました。27の次は2027年3月の28なので、Oracle Premier Supportの観点では27向けの更新はそこで区切られます。日程自体は四半期のCPUと月次のCSPUで構成されます。 ## 関連記事 - [OpenJDKは商用利用できる？無料の範囲とOracle JDKとの違い・ライセンス・サポート期限【2026年最新】](https://www.issoh.co.jp/tech/details/10212/)：Oracle JDK 21のOTNライセンス移行を含む、無償で使える範囲の線引き - [Java SEとは？JDK・JRE・JVMの違いとOracle Java/OpenJDKのライセンスを最新版で解説](https://www.issoh.co.jp/column/details/3113/)：版の話に入る前に押さえるJava SEとランタイムの用語整理 - [Javaモジュールシステムとは？module-info.javaの書き方とパッケージ・ライブラリとの違い](https://www.issoh.co.jp/tech/details/3253/)：プレビュー機能を切り離して置くためのモジュール境界の設計 - [Spring Bootとは｜4.1系の依存名の変更と最小Web APIの作り方](https://www.issoh.co.jp/tech/details/17478/)：JDKの版を決める前に確認するフレームワーク側の対応状況 - [Kotlinとは？Javaとの違いとK2コンパイラ・2.4系の現在地を実装者目線で解説](https://www.issoh.co.jp/tech/details/15789/)：同じJVM上で動く言語側のバージョン事情との比較 --- 出典: [Java 27とは｜非LTSの半年運用とG1・オブジェクトヘッダ既定化の影響]()（株式会社一創）