2018年以降、Javaは6ヶ月ごとに新バージョンをリリースし続けている。直前のLTSであるJava 25（2025年9月）から半年しか経っておらず、本番環境での採用を急ぐ理由は薄い。それでも2026年3月17日にGeneral Availabilityを迎えたJava 26（JDK 26）は、Oracleが非LTSを意図的に「実験の場」として使っていることを最も鮮明に映し出すリリースだ。Java 27（2026年9月予定）が次の正式化の波になるとすれば、Java 26はその準備を整えるための6ヶ月だった。

AD

起動速度・スループット・プロトコル：Java 26の実用改善

エンタープライズへの実用上の影響が最も直接的なのが、JEP 517によるHTTPクライアントAPIのHTTP/3対応だ。HTTP/3はUDPベースのQUICプロトコルを採用し、従来のTCPベースのHTTP/2と比べてヘッドオブラインブロッキング（先頭のパケットロスが後続を止める問題）を回避する設計になっている。接続の再確立コストも低く、モバイル回線のように接続の切り替えが頻繁な環境で特に効果を発揮する。ただしデフォルトのプロトコルはHTTP/2のままで、HTTP/3を使うにはオプトインが必要だ。既存の動作を変えずに新機能を段階的に提供するこの判断は、大規模システムの後方互換性を重視するエンタープライズ向けの設計だ。

G1 GC（Garbage-First Garbage Collector）については、JEP 522「G1 GCのスレッド間同期削減」によって並行処理時のロック競合が緩和された。JEP 522の実装レポートによれば、オブジェクト参照を多用するアプリケーションで5〜15%のスループット向上が確認されている。この改善はヒープサイズや参照グラフの複雑さに依存するため、すべてのワークロードで同じ効果が出るわけではない。マイクロサービス基盤のように短命なオブジェクトが大量生成・破棄される環境では、G1 GCの改善が直接的に効いてくる。

JEP 516はJDK 24で導入されたAOT（Ahead-of-Time）オブジェクトキャッシュ（JEP 483）をZGCを含む全GCに拡張したもので、JVM起動時のヒープオブジェクト再構築コストを削減する。起動時間とメモリ効率を同時に改善するこの機能はクラウドネイティブな短命コンテナ環境と相性がよく、LTSを待たず採用を検討する価値がある実装だ。HTTP/3、G1 GC、AOTキャッシュのいずれも「次のLTSの品質を底上げする」という一貫した設計思想のもとに置かれている。

Unicode 17.0への対応で4,803文字が追加されたことも、実用上の変化として見逃せない。ラテン文字拡張や各種記号の追加を含む今回の更新は、グローバル展開を前提とするアプリケーションで即座に効いてくる変更だ。

5つの「未完成」機能が語るJavaの開発戦略

Java 26に含まれる5つのプレビュー・インキュベーター機能は、いずれも一度や二度の試験を経てきたものではない。構造化並行処理（Structured Concurrency）はJEP 429（JDK 21）以来6回目のプレビューであり、スコープ付き値（Scoped Values）も同様に複数回の改訂を重ねている。プリミティブ型パターンマッチングは4回目のプレビューに入り、Vector APIに至っては11回目のインキュベーターだ。これほど長期にわたって「仮採用」が続く理由は、各機能が他のプロジェクトの完成を待っているからだ。Vector APIの場合、Project Valhallaが提供する値クラス（Value Classes）なしには最終的なAPIデザインを確定できない状態が続いており、リリースごとに機能自体よりも依存関係の進捗がボトルネックになっている。

この構造は、6ヶ月サイクルの設計哲学を正確に体現している。Javaは「リリース日ではなく機能の成熟度で最終化を決める」原則を持ち、プレビュー期間中はAPIが変更される可能性をユーザーに明示する。Java 26では--enable-previewフラグを付けてプレビュー機能を試せる一方、本番採用には向かない。プレビュー期間が長引くことへの批判は開発者コミュニティからも上がるが、Java 17や21での「大型LTSでまとめて正式化」というパターンが繰り返されてきた実績がある。

Oracleは、このJEP群をJava 26で確定させるつもりがなかった。Java 27（2026年9月予定）が次の正式化の波になる公算が高く、Java 26はその準備期間として機能している。JEP 500「Make Final Mean Final」は、finalフィールドをリフレクションで書き換えようとするコードにコンパイラ警告を出す変更で、リフレクション経由でJavaのカプセル化を迂回してきた古いフレームワークへの明確なシグナルだ。JEP 504によるApplet APIの完全削除はJava 9以降長年にわたり非推奨だったAPIをついに取り除いたもので、Java 26は「新機能の追加」と「負債の清算」を並行して進めている。

AD

LTSでない以上、移行する理由はあるか

Java 26はOracle公式サポートが2026年9月までの6ヶ月しかない。Java 25（LTS）はより長期にわたってセキュリティパッチが提供される。この事実だけ見れば、エンタープライズ開発者がJava 26を本番に採用する積極的な理由はほぼない。実際、銀行・保険・製造といった業種では依然としてJava 17やJava 21（LTS）で運用を続ける組織も少なくない。Java 26の価値は「安定した長期運用」ではなく「最新機能への早期アクセス」にある。

HTTP/3のオプトイン試用、AOTキャッシュの動作確認、G1 GCの改善計測——これらはステージング環境やCI/CDパイプラインの評価フェーズに組み込むことで、Java 27への移行判断を前倒しで準備するために使える。Oracle以外のJDKディストリビューター（Amazon Corretto、Eclipse Temurin等）もJava 26のビルドを提供しており、本番デプロイなしにランタイムを評価する選択肢は十分ある。2,535件の修正済みイシュー（うち806件がコミュニティ貢献）の多くは、Java 27のLTSとしての品質を底上げするための積み重ねだ。Javaの6ヶ月サイクルが定着した2018年以降、非LTSリリースの位置づけは「実験場」と「移行準備のランプ」として安定している。

Project ValhallaとJava 27——Java 26が果たす布石

Javaコミュニティで長期にわたり注視されているProject Valhallaは、値クラスとプリミティブ型の統合を目標とするプロジェクトで、10年以上にわたり開発が続いている。値クラスが実現すると、オブジェクトのアイデンティティを持たない軽量データ構造をJVM上で効率的に扱えるようになり、数値計算やデータパイプラインのパフォーマンスが根本から変わる。Java 26でVector APIが11回目のインキュベーターを迎えた背景には、値クラスなしでは最適なSIMD（Single Instruction, Multiple Data（単一命令・複数データ）方式）ベクトル演算APIを設計できないという技術的な依存がある。

Hanno Embregts氏は、AOTキャッシュのZGC拡張とG1 GCの並行処理改善を指して、Java 26が次の大きな変化への基盤を整えたと評価し、2026年後半のProject Valhalla発表への期待を示した。Java 26はその連鎖の前段階として、AOTキャッシュをZGC対応に拡張し、G1 GCの並行処理基盤を整備し、HTTP/3の実装をコミュニティの評価にさらした。

Project ValhallaがJava 27（2026年9月）に間に合うかどうかは、現時点ではまだ確定していない。間に合えば、Vector API・プリミティブ型パターンマッチング・構造化並行処理が連鎖的に正式化される「大型LTS」になる。間に合わなければJava 26と同様の中継地点になる。Java 26とはその判断材料を揃えるための6ヶ月であり、次のリリースを作るための土台だった。

Sources