Java 27リリース――ヒープ使用効率向上と安全性の重視

2026年9月15日（米国時間）にJava 27がリリースされました。

Java 27は、2年ごとのLTS（Long Term Support：長期サポート）バージョンのちょうど中間にあたるバージョンです。そのため、新しい機能の導入はあまりありません。

しかし、LTSに向け安定性や安全性の向上など、ユーザから直接目に触れないような部分が強化されています。

また、Java 27とは直接の関係はありませんが、セキュリティアップデートの変更がありました。本稿では、これについても合わせて紹介していきます。

Java 27の概要

現在、JavaはオープンソースのプロジェクトであるOpenJDKにて開発が行われています。

それぞれのバージョンで導入される機能はJEP（JDK Enhancement Proposal）としてまとめられています。JEPには、複数の種類があり、正式な機能であるStandard JEPと、お試し機能であるPreview JEP、Incubator JEPがあります。

Java 27で導入されるJEPは9あり、そのうちStandard JEPが4、Preview JEPとIncubator JEPが5となります。

Java 27のJEPを以下に示しました。

JEP 523：Make G1 the Default Garbage Collector in All Environments
JEP 527：Post-Quantum Hybrid Key Exchange for TLS 1.3
JEP 531：Lazy Constants（Third Preview)
JEP 532：Primitive Types in Patterns, instanceof, and switch（Fifth Preview)
JEP 533：Structured Concurrency（Seventh Preview)
JEP 534：Compact Object Headers by Default
JEP 536：JFR In-Process Data Redaction
JEP 537：Vector API（Twelfth Incubator)
JEP 538：PEM Encodings of Cryptographic Objects（Third Preview)

Standard JEPのうち、JEP 523とJEP 534がヒープに関するJEPです。JEP 527とJEP 536は安全性に関するJEPとなります。本稿では、この4つのStandard JEPを中心に解説を加えていきます。

JEP 523⁠：Make G1 the Default Garbage Collector in All Environments

Javaはガベージコレクション（GC）を使用して、ヒープを管理します。GCには複数の種類があり、シリアルGC、パラレルGC、Garbage First GC（G1GC⁠）⁠、ZGC、Shenandoah GCなどが提供されています。

これらのGCは起動時のオプションによって指定することができますが、デフォルトで使用されるGCは機器のリソースによって決められてきました。

従来はCPUやメモリに余裕のあるサーバではG1GC、リソースが限られた環境ではシリアルGCがデフォルトのGCとして使用されてきました。

その一方で、G1GCはJava 26で導入されたJEP 522：G1 GC: Improve Throughput by Reducing Synchronizationなど着実に改良されてきました。これらの改善により、リリースが限られた環境においてもシリアルGCと同等のパフォーマンスを得ることが可能になりました。

そこで、Java 27からは、これまでシリアルGCがデフォルトGCとなっていた低リソースの環境においても、G1GCがデフォルトのGCとなりました。

この変更により影響を受けやすいのが、コンテナやサーバレスでJavaを使用する場合です。もし、シリアルGC用にチューニングを行っている場合は、そのままシリアルGCを使い続けるようにするか、G1GC用に設定を見直す必要があります。

JEP 534⁠：Compact Object Headers by Default

Javaのオブジェクトはヒープに配置されます。個々のオブジェクトは固有のメタデータを持ち、それをオブジェクトのヘッダに保持しています。

従来、オブジェクトヘッダは最大128bit（16byte）を使用していました。しかし、これだと小さなオブジェクトの場合ヘッダの方が大きくなってしまうこともあります。個々のオブジェクトヘッダのサイズは小さくとも、値オブジェクトを大量に使用するようなシステムではヘッダのサイズがバカになりません。

そこで、Java 25で導入されたのが、Project Lilliputが仕様策定を行ってきたJEP 519：Compact Object Headersです。JEP 519によりオブジェクトヘッダは64bit（8byte）と半分のサイズになりました。

JEP 519はStandard JEPですが、64bitのヘッダを使用するには起動時に指定する必要がありました。

これに対し、Java 27からはデフォルトで64bitのヘッダが使用されるようになります。この変更によってヒープ使用量の削減を期待できます。

なお、Project LilliputのLilliputはガリバー旅行記に出てくる小人の国リリパットに由来しています。

JEP 527⁠：Post-Quantum Hybrid Key Exchange for TLS 1.3

量子コンピュータを使用しても安全だと考えられているのがポスト量子暗号（PQC：Post-Quantum Cryptography）です。現状では、既存の暗号アルゴリズムを破るほどの性能を持つ量子コンピュータは存在しませんが、今後考えられる脅威に今から対応する必要があります。

Javaでは、すでにJava 21で鍵のカプセル化（KEM：Key Encapsulation Mechanism）のAPIが導入され、Java 24でポスト量子暗号アルゴリズムの1つであるML-KEM（Module-Lattice-Based Key Encapsulation Mechanism)が導入されています。

Java 27では、TLS 1.3で策定されたPQCの鍵交換をサポートするようになりました。しかも、TLS 1.3を使用していれば既存のコードを変更することなくPQCの鍵交換を行うことができます。

JEP 536⁠：JFR In-Process Data Redaction

JFR（JDK Flight Recorder）は、標準で使用できるアプリケーションの監視やプロファイリングを行うフレームワークです。

JFRでは収集した情報をファイルに記録しておき、後から解析をすることができます。この時にコマンドライン引数や環境変数なども一緒に記録します。しかし、起動時にコマンドライン引数でパスワードなど機密情報を指定することもあります。

従来のJFRの記録ファイルにはこれらの機密情報もそのまま記録していたため、ここから機密情報が漏洩してしまうリスクがあります。

そこで、JEP 527では機密情報に相当する情報を記録しないように指定できるようになりました。

記録しない情報を指定するには起動時に-XX:FlightRecorderOptionsで指定します。

指定の方法は2種類あります。コマンドライン引数や環境変数は一般的に"キー=値"形式で記述します。この時に、キーを指定して記録しないようにすることと、特定のパターンの値を記録しないようにすることの2種類です。前者にはredact-key、後者にはredact-argumentを使用します。

たとえば、キーがconfidentialのものを削除し、値としてURLがhttps://address/username:password@hostのようにユーザネームやパスワード、ホストを含むような値を削除するには次のように指定します。

java -XX:FlightRecorderOptions:'redact-key~=confidential,redact-argument=https://:@*' -XX:StartFlightRecording:filename=jfrdump.jfr -jar application.jar

その他のJEP

ここまではStandard JEPを紹介してきましたが、Preview JEPとIncubator JEPについても簡単に紹介しておきます。

JEP 531⁠：Lazy Constants（Third Preview）

Lazy Constantsはクラスのfinalフィールドを安全に遅延初期化するためのAPIです。Java 27では3回目のプレビューになり、小規模なAPIの変更がありました。

Java 28でのLazy ConstantsのJEPもすでに登録されています。Java 28ではJava 27から変更がないので、Java 29にはStandard JEPになることが予想できます。

JEP 532⁠：Primitive Types in Patterns, instanceof, and switch（Fifth Preview)

プリミティブ型をパターンマッチングで使えるようにするのが、JEP 532です。Java 26からの変更はありませんが、もう一度プレビューを行っています。このため、次のJava 28ではStandard JEPになると思われます。

JEP 533⁠：Structured Concurrency（Seventh Preview）

Structured Concurrencyを使用することで、複数スレッドでの処理結果をまとめることが簡単にできます。もともとはVirtual Threadと同時期に導入予定でしたが、なかなかStandard JEPになりませんでした。Java 27でもいくつかのAPIの変更が加わっています。

しかし、Structured Concurrencyは次のJava 28でStandard JEPに昇格することが決まっています。

JEP 537⁠：Vector API（Twelfth Incubator）

1つの命令で複数のデータをまとめて演算するSIMD命令に対応するのがVector APIです。Vector APIはProject ValhallaのValue Classが導入されるまで、インキュベータのまま継続されることになっています。

Value ClassのJEP 401はずっとターゲットとなるバージョンが決まらなかったのですが、Java 28でようやく1回目のプレビューが決まりました。Vector APIがStandard JEPになるのも、もう少しというところではないでしょうか。

JEP 538⁠：PEM Encodings of Cryptographic Objects（Third Preview）

JEP 528は、Private-Enhanced Mail形式で暗号鍵、証明書などを扱うためのAPIです。Java 26でも変更点が多かったのですが、Java 27でもまだ変更点が多いため、Standard JEPになるにはもう少し時間がかかりそうです。

セキュリティアップデート

今までOracleが提供していたセキュリティアップデート(CPU：Critical Patch Update）は、1月、4月、7月、10月に行われてきました。たとえば、2026年3月にリリースされたJava 26に対しては、4月にJava 26.0.1、7月にJava 26.0.2が提供されています。

これに対し、より頻繁に優先度の高いセキュリティ修正を行うCSPU（Critical Security Patch Update）が2026年8月から提供されることになりました。CSPUは2月、3月、5月、6月、8月、9月、11月、12月に提供されます。

CPUも引き続き提供されるので、CSPUを合わせると毎月セキュリティアップデートがあることになります。

すでに8月に、CSPUに対応するJava 26.0.2.1がリリースされています。

これはOracleだけではなく、他のJavaのディストリビュータでも追従するようです。詳しくはご使用のJavaのディストリビュータにお尋ねください。

参考:

おわりに

Java 27はLTSの中間のバージョンであるからか、比較的変更の少ないバージョンとなりました。APIの変更はなく、ヒープの管理やセキュリティなど安心してJavaを使えるようにする変更だけになっています。

とくにデフォルトのGCの変更は、Javaを使用しているコンテナ環境で使用している場合に影響があります。今までのシリアルGCを使い続けるのか、G1GCを評価して導入するかなどの判断が必要になるかもしれません。

次のJava 28は、パターンマッチングにおけるプリミティブ型のサポートや、Structured Concurrencyなど言語仕様やAPIの変更が予定されています。また、PreviewとしてValue Classも提供される予定です。

最後にJavaに関するトピックを2つ紹介しましょう。

1つ目が来年のJavaOneが2027年3月23日から3日間に渡り開催されることが発表されました。筆者も参加する予定ですので、ぜひ現地でお会いしましょう。

JavaOne 2027公式サイト

もう1つが、Javaの30周年を記念して、テクノロジ系のドキュメンタリを作成しているCultRepoがJavaのドキュメンタリー『The Java Story』をYouTubeで公開したことです。

Javaの父James Gosling氏や、現在OpenJDKでJavaのアーキテクトをしているMark Reinhold氏やBrian Goetz氏まで多くの人のインタビューから構成されており、なかなか見ごたえのあるドキュメンタリになっています。

ぜひご覧になってみてください。