---
source_url: https://www.jvm-weekly.com/p/project-valhalla-explained-how-a
source_title: "Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 - JVM Weekly vol. 180"
source_site: "JVM Weekly"
source_published_at: 2026-06-18T13:03:29+00:00
hero_image: https://substackcdn.com/image/fetch/$s_!3GhD!,w_1200,h_675,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4d9124f8-8a73-453b-88e2-7df5c98022ec_1920x1080.png
tags: java,valhalla,jdk28
generated_at: 2026-06-19T12:00:45.154Z
model: claude-haiku-4-5
---
# Project Valhalla、JDK 28でプレビュー機能として統合へ

JDK 28を対象とした「JEP 401: Value Classes and Objects」の統合が確認されました。Oracle エンジニアの Lois Foltan が6月15日に発表した大規模な変更は、OpenJDK リポジトリに19万7千行以上のコードを追加する予定です。

## 統合の詳細と規模

6月15日、Oracle エンジニアの Lois Foltan は、JEP 401: Value Classes and Objects が OpenJDK リポジトリのメインブランチに統合され、JDK 28 をターゲットとすることを確認しました。この統合は極めて大規模であり、残りのコミッターには統合期間中の大型コミットを控えるよう要請されています。プルリクエスト単体で19万7千行以上のコードが1,816ファイルにわたって追加されます。

![Project Valhalla integration](https://substackcdn.com/image/fetch/$s_!3GhD!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4d9124f8-8a73-453b-88e2-7df5c98022ec_1920x1080.png)

本機能はプレビュー段階であり、デフォルトで無効化されています。ただし Brian Goetz は、これが 「Valhalla の最初の部分に過ぎない」とコメントしており、今後の段階的な展開が予定されていることを示唆しています。

## Value クラスの設計と制限

Value クラスは value 修飾子を使用して宣言されます。すべてのインスタンスフィールドは暗黙的に final となり、Value クラス自体も final がデフォルトです。Value クラス内のメソッドは同期化（synchronized）を使用できません。

Value オブジェクトはアイデンティティを持たず、通常のオブジェクトとは異なります。== 演算子はアイデンティティではなく置換可能性（substitutability）を検査します。JDK 28 では Value オブジェクトは依然として null となる可能性がありますが、非 null 型は別の JEP として将来的に対応予定です。

Value クラスは Value クラスと abstract Value クラスで構成される階層構造を形成でき、インターフェースの実装も可能です。ただし、アイデンティティを持つクラスからの継承はできません。

## Project Valhalla の進化と実装技法

Project Valhalla は 2014 年に正式に開始し、プロジェクト期間中に 5 つの異なるプロトタイプが構築されました。L World プロトタイプは 2019 年頃に誕生しました。実装には Scalarization と Heap flattening という 2 つの JIT コンパイラ技法が活用されます。Scalarization は Value オブジェクト参照をフィールドに分解する技法であり、Heap flattening はオブジェクトの本質をコンパクトなビットベクトルとしてエンコードします。

![Scalarization technique](https://substackcdn.com/image/fetch/$s_!Nxmc!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F0333ea9a-5db7-4b0b-9dfe-ae446b56b623_737x374.png)

プリミティブ ラッパー クラスはプレビュー段階で Value クラスになります。64 ビットは典型的なプラットフォームでフラット化されたデータの原子書き込みサイズであり、将来的には 128 ビットまで拡張される見込みです。JEP 401 の設計目標は 「クラスのようにコードでき、int のように動作する」ものです。

## 筆者の見立て

- 経験豊富な JVM プログラマーは escape analysis を素晴らしいボーナスではなく、プロジェクトの基盤として扱う傾向があると論じている
- Scalarization は通常、変数の型が Value クラスのスーパータイプである場合には機能しないと解釈している
- データ集約的なコードでは複数倍の差が生じる可能性があると予想している
- 最終的にコレクション、ストリーム、および API 全体が Value 型上でフラットでアロケーション不要になる可能性を示唆している
- 特殊化からの完全な報酬は将来のリリースの問題であると予想している

*この記事は元記事の事実のみに基づいて自動生成されました。*

## 出典

**JVM Weekly** 「Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28 - JVM Weekly vol. 180」  
https://www.jvm-weekly.com/p/project-valhalla-explained-how-a

(JEP 401、JEP 402: Enhanced Primitive Boxing、Baeldung の報道による)