Java 27の新機能まとめ｜値クラスとJDK 28も解説

Java 27（JDK 27）は2026年9月15日にリリースされた、6ヶ月サイクルの最新版です。LTS（長期サポート版）ではありませんが、「コードを1行も変えずにヒープが軽くなる」「量子コンピュータ時代の暗号に標準対応」という、業務システムにも効く変更が入っています。さらにJDK 28の早期アクセス版では、30年来の課題に答える値クラス（Project Valhalla）がプレビューとして統合されました。

この記事では、Java 27の新機能をJEP番号・フラグ・コード例つきで、「今すぐ効くもの」「プレビューで先取りするもの」「JDK 28以降の大きな変化」に分けて、金融業界向けJava 21プロジェクトなどを手がける株式会社RJCの視点で解説します。

Java 27の位置づけ：LTSとの関係

Javaは6ヶ月ごとに新版が出て、2年ごとにLTSが指定されます。直近のLTSはJava 21（2023年）とJava 25（2025年）、次のLTSはJava 29（2027年予定）です。

Java 27は非LTSなので、本番の基盤を移すというより、次のLTS（29）で何が来るかを先に体験し、CIで互換性を検証しておく版と捉えるのが現実的です。ただし、後述するヘッダ圧縮やGCの既定化は、次のLTSにそのまま入ってくる変更なので、内容を知っておく価値は高いです。

Java 27のJEP一覧（早見表）

今すぐ効く変更（コード変更不要）

コンパクトオブジェクトヘッダが既定に（JEP 534）

すべてのJavaオブジェクトには、GCやロック管理のための「ヘッダ」が付いています。従来は96ビット（12バイト）でしたが、Java 27では64ビット（8バイト）のコンパクトヘッダが既定になりました。Java 25までは -XX:+UseCompactObjectHeaders を自分で付ける必要があった機能が、何もしなくても有効になります。

たった4バイトの差ですが、Javaのヒープは小さなオブジェクトの集合体です。効果を概算すると——

// 例: 8バイトのフィールドを持つ小さなオブジェクトが1億個あるヒープ
従来:   (12 + 8) バイト × 1億 ≒ 2.0 GB
Java 27: (8 + 8) バイト × 1億 ≒ 1.6 GB   // それだけで約2割減

公開されているベンチマークでは、小さなオブジェクトが多いアプリでヒープ最大20%減・スループット最大10%向上が報告されています。ヒープ削減はGCの頻度と停止時間の削減にも繋がるため、長時間稼働する業務システムほど恩恵が大きい変更です。

自分のアプリでの効果は、起動して同条件で比較すれば測れます。

# Java 27の既定（コンパクトヘッダON）でヒープを観察
jcmd <PID> GC.heap_info

# 旧ヘッダに戻して比較したいとき
java -XX:-UseCompactObjectHeaders -jar app.jar

G1が全環境で既定のGCに（JEP 523）

これまで、コンテナのメモリやCPUが小さい環境では自動的にSerial GCが選ばれることがあり、「本番と開発でGCが違う」という混乱の元でした。Java 27でG1 GCが全環境の既定となり、この不整合が解消されます。

# いま何のGCが動いているかの確認
java -XX:+PrintFlagsFinal -version | grep 'Use.*GC.*true'

# 小メモリ環境で従来どおりSerial GCを使いたい場合（明示指定は引き続き可能）
java -XX:+UseSerialGC -jar app.jar

1コア・数百MBのような極小コンテナでは、Serial GCの方がフットプリントが小さいこともあります。既定が変わっただけで、選択肢が消えたわけではない——上のフラグで従来の挙動に戻せます。

ポスト量子暗号（PQC）のハイブリッド鍵交換をTLS 1.3でサポート（JEP 527）

将来の量子コンピュータによる解読に備え、従来方式（楕円曲線）と耐量子方式（ML-KEM）を組み合わせた鍵交換をTLS 1.3で行えるようになりました。既定で有効なハイブリッド方式は X25519MLKEM768 で、通信相手が対応していれば自動的に選択されます。

# 使う鍵交換グループを明示したい場合
java -Djdk.tls.namedGroups=X25519MLKEM768,SecP256r1MLKEM768 -jar app.jar

# ハンドシェイクで実際に何が選ばれたかの確認
java -Djavax.net.debug=ssl:handshake -jar app.jar

「いま盗んで、あとで解読する」という脅威に対し、金融・公共といった長期の機密性が求められる領域で、プラットフォーム標準として先回りした形です。

JFRが機密データを自動でマスキング（JEP 536）

地味ながら運用に効くのがこれです。本番でも使える標準プロファイラのJFR（Java Flight Recorder）が、記録に含まれる機密らしき値を自動でマスキングするようになりました。

既定では *password*、*token*、*secret*、*api*key* などのパターンに合う名前の値が対象です。対象は追加・変更できます。

# 独自の環境変数名やシステムプロパティを対象に追加
java -XX:FlightRecorderOptions:'redact-key=+*confidential*' -jar app.jar

# マスキングを無効化（従来どおりの記録）
java -XX:FlightRecorderOptions:'redact-key=none,redact-argument=none' -jar app.jar

「JFRの記録ファイルを社外のサポートに送ったら、環境変数のAPIキーが入っていた」——そんな事故を、JVMの層で防いでくれます。

プレビューで先取りする機能

プレビュー機能は --enable-preview を付けて試せる段階の機能で、仕様が変わる可能性があります。本番採用はまだ避けつつ、次のLTSに向けて学んでおく価値があるものです。

Lazy Constants（プレビュー3回目・JEP 531）

「初回アクセス時に一度だけ初期化され、以後は定数として扱われる」値を、スレッドセーフに書ける仕組みです。ダブルチェックロッキングの自作が要らなくなります。

// 生成が重いオブジェクトを、最初に使われた瞬間に1回だけ作る
private final LazyConstant<Validator> validator =
        LazyConstant.of(this::createValidator);

// 使うときは get() するだけ。2回目以降は初期化済みの値が返る
validator.get().validate(input);

JVMが「実質final」と分かる形なので、将来的な最適化（定数畳み込み）の余地も残る設計です。

プリミティブ型のパターンマッチ（プレビュー5回目・JEP 532）

switch や instanceof のパターンとして、intなどのプリミティブ型を直接使えるようになります。

int score = ...;
String rank = switch (score) {
    case int s when s >= 90 -> "A";
    case int s when s >= 70 -> "B";
    default                 -> "C";
};

参照型で揃っていたパターンマッチの世界に、プリミティブが合流する形です。record・sealedと組み合わせたデータ指向の書き方が、さらに素直になります。

構造化並行性（プレビュー7回目・JEP 533）

並行タスクを「親子関係を持つ1つの単位」として扱い、エラー処理とキャンセルを構造的に安全にするAPIです。Java 27では、タイムアウトを構成時に指定する形などが整理されました。

try (var scope = StructuredTaskScope.open(
        cfg -> cfg.withTimeout(Duration.ofSeconds(2)))) {

    var user  = scope.fork(() -> fetchUser(id));     // 並行に実行
    var order = scope.fork(() -> fetchOrders(id));   // 並行に実行

    scope.join();   // 全部の完了を待つ。1つ失敗すれば残りは自動キャンセル
    render(user.get(), order.get());
}

仮想スレッド（Java 21で正式化）と組み合わせて、「1リクエストの中で複数のAPIを並行に呼ぶ」処理を、リークもキャンセル漏れもない形で書くための本命です。7回目のプレビューで、正式化が近づいています。

暗号オブジェクトのPEM入出力（プレビュー3回目・JEP 538）

証明書や秘密鍵の定番フォーマットPEM（-----BEGIN PRIVATE KEY----- のあれ）を、標準APIで読み書きできるようになります。これまで自前のパースやライブラリ頼みだった処理が、数行になります。

// パスフレーズ付きの秘密鍵PEMを読み込む
PrivateKey key = PEMDecoder.of()
        .withDecryption(passphrase.toCharArray())
        .decode(pemText, PrivateKey.class);

Vector API（インキュベーター12回目・JEP 537）

SIMD命令を扱うVector APIは、Java 27では変更なしの継続です。12回もインキュベーター段階に留まっている理由は、後述のValhallaの値クラスで型を正しく表現できるようになるのを待っているため。機能同士が10年単位で連携しているのが、JDK開発の設計の深さです。

JDK 28で来る大きな変化：値クラス（Project Valhalla・JEP 401）

Java 27と同時期に、JDK 28の早期アクセス版でProject Valhallaの値クラス（JEP 401: Value Objects, Preview）がプレビューとして統合されました。約10年の設計議論、変更約19万行という、Javaの30年来の宿題に答える変更です。

値クラスとは何か

Javaには誕生以来、プリミティブ（intなど）とオブジェクトの間の溝がありました。プリミティブは速いがオブジェクトとして扱えず、オブジェクトは柔軟だがヒープに個別に置かれて重い。

値クラスは、value という修飾子を付けるだけで、そのインスタンスが「識別性（アイデンティティ）」を持たないオブジェクトになります。

value record Point(int x, int y) {}

// 識別性が無い＝「どの箱か」ではなく「どんな値か」だけで区別される
Point a = new Point(1, 2);
Point b = new Point(1, 2);
a == b        // → true（通常のクラスならfalse。フィールドの値で比較される）
synchronized (a) { }   // → コンパイルエラー（ロックの対象にできない）

識別性を手放す代わりにJVMは、値オブジェクトをヒープに個別に置かず、配列やフィールドの中に平たく展開（フラット化）できるようになります。

Point[] points = new Point[1_000_000];
// 従来:   参照の配列 → 100万個のオブジェクトがヒープに散らばる
// 値クラス: int x, y が配列の中に直接ぎっしり並ぶ（参照もヘッダも無し）

何が変わるのか

• メモリ密度が上がる — 座標・金額・日付のような小さな不変データを大量に扱う処理で、ヒープ使用量とキャッシュ効率が改善する
• 既存の「値ベースクラス」が移行対象になる — Integer などのラッパークラスも、将来的に値クラスへ移行する方向で設計されています
• Vector APIが正式化に近づく — 値クラスで型を正しく表現できるため

構文の変更は value の一語ですが、影響は大きい。JDK 28の正式版は2027年3月予定で、まずはプレビューとしての提供になります。

業務システム開発者はどう向き合うか

1. Java 27はCIで回す — 本番はLTS（21または25）のまま、テストスイートをJava 27で走らせてヒープとGCの変化を計測しておく
2. ヘッダ圧縮の効果を見積もる — 次のLTSで既定になる変更なので、jcmd GC.heap_info の前後比較をいま取っておくと、インフラのサイジングにそのまま使える
3. 値クラスの設計思想を先に理解する — 「不変で小さいデータをrecordで定義しておく」習慣が、そのまま値クラスへの布石になります。value を前置するだけの距離に置いておく
4. PQCの要件を確認する — 長期の機密性が求められるシステムは、TLSのハイブリッド鍵交換をいつ有効化するか、方針を決めておく

RJCでは金融業界向けのJava 21プロジェクトなど、長期サポート版で堅い業務システムを開発しています。だからこそ、次のLTSで何が来るかを追い続けることが、設計判断の質になると考えています。

よくある質問

Q. Java 27に今すぐ移行すべきですか？
A. 本番は原則LTS（21・25）で運用し、Java 27はCIでの互換性検証と効果測定に使うのが現実的です。次のLTSであるJava 29（2027年予定）への移行を滑らかにする準備期間と捉えてください。

Q. コンパクトオブジェクトヘッダは、どれくらい効きますか？
A. オブジェクトの平均サイズと数に依存します。小さなオブジェクトが多いアプリで最大20%程度のヒープ削減が報告されていますが、まず自分のアプリで jcmd GC.heap_info の前後比較を取るのが確実です。

Q. プレビュー機能を本番で使ってもいいですか？
A. 避けてください。プレビューは仕様が変わり得る段階で、--enable-preview を付けたバイナリはそのバージョンのJVMでしか動きません。学習と検証に使い、本番は正式化を待つのが原則です。

Q. 値クラスはいつ本番で使えますか？
A. JDK 28（2027年3月予定）でプレビューとして提供される段階です。正式化はその先になるため、本番採用はまだ先ですが、設計思想を理解しておく価値はあります。

Q. Javaは本当にまだ進化しているのですか？
A. 30年の互換性を守りながら、内部構造（ヘッダ・GC）・並行モデル・暗号・データ表現（値クラス）を作り替え続けています。動いているシステムを止めずに未来へ運ぶ技術こそ、Javaの本領です。

まとめ

Java 27の要点は、「コードを変えずに軽くなる」（JEP 534ヘッダ圧縮・JEP 523 G1統一）と「未来の脅威に先回りする」（JEP 527 PQC・JEP 536 JFRマスキング）の2つ。そして視線の先には、JDK 28の値クラス（JEP 401）があります。

Javaの進化は、新しい構文の派手さではなく、動いているものを止めずに内部を最先端にするところにあります。次のLTSに向けて、いま計測と学習を始めておく価値のある版です。

参考：Oracle Java 27発表（2026年9月15日）／OpenJDK JEP 534・523・527・536・531・532・533・538・537／OpenJDK Project Valhalla「JEP 401: Value Objects (Preview)」（2026年9月時点）