Java 業界の歴史を覆す JEP 401「Value Classes」：JDK 28 で実現される「ヴァレハラ（Valhalla）」

6 月 15 日、Oracle エンジニアのロイス・フォルトン氏により、事実上の合意が JDK への公式統合が確定したことが発表されました。JEP 401（Value Classes and Objects）がメインの OpenJDK リポジトリに追加され、JDK 28 を目標とした開発を開始します。

• 規模は巨大: プレビュー機能として承認されており、デフォルトでは無効化されています（

  --enable-preview

  フラグが必要）。
• コミットの差し控え: 統合中のコミッターに対して、大規模なコミットが一時保留されるよう要請されました。
• 変更の範囲: シングルな Pull Request で、1,816 ファイルを横断し 197,000 行以上のコードが追加されました。
• 現状の立ち位置: ブライアン・ゴーツ氏はこれを「ヴァレハラの最初の部分に過ぎない」と述べており、完全に shipping（製品版としてリリース）されるのは将来的な話です。

なぜこの変更が必要なのか：Java の根本的な問題

プリミティブとオブジェクトの二項対立

• Java ではすべてのデータが参照型であり、プリミティブ型（int, long 等）とは異なるメモリ管理を行います。
  • 例:

    Point p = new Point(1, 2)

    と書いた場合、

    p

    は点そのものではなく、ヒープ上のオブジェクトへの**ポインタ（住所）**です。
• 問題となるのはスケール:
  • 各オブジェクトにはヘッダー（型情報や同期状況など、約 12 バイトのメタデータ）が存在します。
  • ガベージコレクション（GC）の負荷がヒープ上の「散らばった箱」の数に比例して増加します。
• 「ふっくらした」メモリ配置: ブライアン・ゴーツ氏が形容する、密度が高くキャッシュ効率的でない状態です。

ハードウェア進化とのギャップ

• CPU 演算速度はメインメモリの約 2 桁上回っており、キャッシュがボトルネックになっています。
• プロセッサはデータを読み取る際、64 バイトのキャッシュライン単位で動作します。
• 参照の局所性の欠如: ポインタ経由での間接参照は、キャッシュミスを招きやすく、ヒットした場合と比べて約 100 倍遅い可能性があります。

エスケープ分析の限界

• JIT コンパイラがエスケープ分析を用いてオブジェクトをローカルに展開（スカラー化）する仕組みがありますが、これには弱点があります。
  • 予測不可能: アライメントやガベージコレクションのコストは、コンパイル時の最適化状況に依存するため不安定です。
  • 脆弱性: コードの単純なリファクタリングや JDK 更新により、再びヒープ上のオブジェクト扱いに戻り、パフォーマンスが低下するリスクがあります。

プロジェクトヴァレハラの進化史：12 年間の試行錯誤

プロジェクトは 2014 年に開始され、「クラスのようにコードし、int のように動作する」という目標を掲げてきました。数々のプロトタイプが死滅した道のりがありました。

用語とモデルの変遷

• 第 1 段階：value types：概念の初期段階。プリミティブ型と全く別の「生き物」として扱うアプローチでした。
• 第 2 段階：inline classes（2019-2020 年）：
  • クラスを「アイデンティティを持つもの（Identity Classes）」と「アイデンティティを持たないもの（Inline Classes）」に分けました。
  • スローガン「クラスのようにコードし、int のように動作する」が確立されました。
• 第 3 段階："primitive classes"および二重射影モデル：
  • 一つの型が

    Value Variant

    （プリミティブ風）と

    Reference Variant

    （null を許容するボックス）の 2 つの状態を持つモデルでした。
  • メリットがあったものの、プログラマが常に両方の形式を理解する必要があり、メンタルコストが高すぎると判断されました。
• 第 4 段階（現在）：Value Classes と Value Objects：
  • 複雑な二元論を捨て、以下の 2 つの独立した概念に分解しました。
    1. アイデンティティの有無 (

       value

       modifier で宣言されたクラスは Identity を持たない)
    2. null の許容性 (非 null 制限は別の JEP に分離され、JDK 28 では未実装)

コードの歴史に残る教訓

「コードを書く」ことではなく、「アイデアを拒否し続けることで残るのが本質」である 12 年間でした。

• Universal Generics（汎用ジェネリクス）: 取り下げられ、Specialized Generics に再考されました。
• 「primitive classes」の名前: オープン JDK の典範としてはもはや使用されず、現在は「Value Classes」と呼ばれます。

JEP 401 の具体的な機能と動作

宣言と定義的特徴

value

value class USDCurrency implements Comparable<USDCurrency> {
    private int cents; // 暗黙的に final
    public USDCurrency(int dollars, int cents) {
        this.cents = dollars * 100 + cents;
    }

    public USDCurrency plus(USDCurrency that) {
        return new USDCurrency(0, this.cents + that.cents);
    }
}

制約事項

• アイデンティティなし:

  new Point(1,2)

  と作成した 2 つのオブジェクトは、「内容が同じ」だけでなく「同一」とみなされます。
• Final の強制: 全てのフィールドは暗黙的に

  final

  、クラス自体もデフォルトで

  final

  です。
• メソッド制約: メソッドは

  synchronized

  を使用できません（IdentityException を投げるため）。
• 継承と実装: アイデンティティを持つクラスからの継承は不可ですが、インターフェースの実装は可能です。

重要な概念：スカラー化（Scalarization）とヒープフラットニング

JVM に Value Objects の最適化を許容する 2 つの方法があります。

1. スカラー化 (Scalarization):
   • JIT コンパイラによる手法。Value Object の参照が「素因数分解」され、ポインタ不要のフィールドセットとして処理されます。
   • 効果: 割り当てと GC のコストが発生せず、エスケープ分析以上の範囲で機能します。
2. ヒープフラットニング (Heap Flattening):
   • オブジェクトがメモリ上の別の場所へのポインタを持たず、アレイセルに直接書き込まれます。
   • 効果: データ密度とキャッシュ効率の最大化（参照の局所性の向上）。

注意: 完全にフラット化するには原子性が必要です。将来的には 128 ビットエンコーディングや非 atomic な保証を放棄した型も登場する可能性があります。

プリミティブ型への統合

• プレビュー機能で有効な場合、

  Integer

  ,

  Long

  ,

  Double

  などのラッパークラス自体が Value Class となります。
• これにより、

  Integer[]

  や

  List<int>

  のような構造を、従来のオブジェクトとは異なる効率的なメモリ配置（フラット化）として扱うようになります。

バランスの取れた抽象化

• メリット: プリミティブ型の密度とクラスの可読性の両方を得ることができます。
  • 例:

    Color

    クラスを持たず、

    r

    ,

    g

    ,

    b

    の 3 バイトを持つように記述できますが、名前やメソッドで記述できるため誤解を防げます。
• デメリット: デフォルトでは null を許容するため（別途 JEP で対応）、厳密な null 安全性を得たい場合は追加のステップが必要です。

ジェネリクスとコレクションへの適用課題

Java のジェネリクスは「タイプ消去」により実装されているため、

List<Point>

ロードマップ：Universal Generics vs Specialized Generics

• 第 1 フェーズ：Universal Generics (言語レベル)
  • 型変数が Value Types も含むことを可能にしますが、依然としてタイプ消去を通じた実装です。
  • プログラムは「null ポリューション」の警告を受け、API の専門化（specialization）準備が求められます。
• 第 2 フェーズ：Specialized Generics (JVM レベル)
  • コンテナ自体を Value Types で裏付け、

    ArrayList<Point>

    を本当にフラットなメモリ構造として実装します。
  • 現状: まだ研究・開発段階であり、JDK 28 には完全導入されていません。

まとめ：なぜこれが歴史的大変革なのか

「アイデンティティ」前提の転換

1995 年以来、「すべてのオブジェクトはアイデンティティを持つ」という Java の根幹が揺らぎます。プログラマに選択肢を与えることは、単なる機能追加ではなく基礎のシフトです。

プレビューと将来性

• JDK 28 (目標): Value Classes と Objects の基本機能（スカラー化、フラットニング）の実装。
  • LTS リリースではないため、次期 LTS は JDK 29 です。

  • --enable-preview

    フラグが必要です。
• 将来の拡張: 非 null タイプ、完全な Specialized Generics、128 ビットエンコーディングなどは、JDK 28 以降に順次実装が予定されています。

アクションプラン

• 実験的利用: 早期アクセスビルドは

  jdk.java.net/valhalla

  で入手可能です。
• 移行戦略: データ集約型コード（ML、ゲーム、金融計算など）において、パフォーマンスを犠牲にせず密度のあるデータ構造を持つことが可能になります。
• 注意点: エスケープ分析や Identity に依存していた既存のコードは、Behavior が変わる可能性があります（特に

  ==

  や

  synchronized

  的使用）。

このプロジェクトが JDK の進化を加速させ、抽象化と性能の両立を達成する鍵となることは間違いありません。