Java Project Valhalla：長年の Java 開発者として期待していること

まとめ

Java Project Valhalla とは何か、Java の性能は本当に良くなるのか。 そう調べている人に向けて、この記事では value class、アイデンティティのないオブジェクト、フラット化・スカラー化という方向性を整理します。私は長く Java を主力として使ってきた開発者として、Valhalla を「Java が別の言語になる話」ではなく、「Java らしさを保ったまま長年の弱点を減らす試み」と見ています。

最近は Python、Go、Rust も使います。AI のおかげで Python での実験は速くなり、Go や Rust の軽さも魅力的です。それでも、長期運用する大規模システムでは Java の安定感を簡単には捨てられません。だからこそ Valhalla には、期待しつつもプレビュー機能として慎重に見ています。

目次

Java の性能に再び注目する理由

Java は大規模なバックエンド、バッチ、API、長期運用システムで今も強い選択肢です。JVM、Spring、監視や運用ツールの成熟度は大きな利点です。一方で、小さなオブジェクトを大量に作るコードでは、メモリ使用量、割り当て、GC、キャッシュ局所性が気になります。

長く Java を使っていると、きれいなドメインモデルを保ちたいのに、性能のために long、int、配列、専用バッファへ戻したくなる場面があります。この妥協を少しでも減らせるなら、Java 開発者として期待したくなります。

Project Valhalla が解こうとしている問題

Money、Point、Range、UserId のような小さな値オブジェクトは、コードの意味を明確にします。しかし通常のオブジェクトとして大量に作ると、ヒープ割り当てや参照追跡のコストが出ます。

きれいなドメインモデルを保つのか？
それとも性能のために primitive と配列へ崩すのか？

Valhalla は、この溝を埋めるために Java オブジェクトモデルへ値オブジェクトを導入し、オブジェクト指向の抽象化とプリミティブに近い性能特性を組み合わせようとしています。

値クラスとアイデンティティのないオブジェクト

JEP 401 の中心は Value Classes and Objects です。通常の Java オブジェクトにはアイデンティティがあります。同じフィールド値でも、別のオブジェクトなら == は false になり得ます。

new Point(1, 2) != new Point(1, 2)

値オブジェクトでは、重要なのは「どこにあるオブジェクトか」ではなく「どの値か」です。JEP 401 の例は次のように理解できます。

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

Point p = new Point(17, 3);
Objects.hasIdentity(p);      // false
new Point(17, 3) == p;       // true

従来のオブジェクト:
配列 → 参照 → ヒープ上のオブジェクト → フィールド

value object で期待される最適化:
配列やフィールドに値をより直接・コンパクトに配置できる可能性

性能改善はどこまで期待できるか

期待はできます。ただし、すべての Java コードが自動的に速くなるわけではありません。効果は JVM 実装、JIT、コード形状、データ量、GC 条件によります。

1. 小さなオブジェクトの割り当てを減らせる可能性

値にアイデンティティがなければ、JVM は各インスタンスを必ず独立したヒープオブジェクトとして扱う必要がなくなる可能性があります。

2. メモリレイアウトが改善される可能性

Point[] が参照の配列ではなく、より値に近い形で扱えるなら、CPU キャッシュ局所性やメモリ使用量に利点が出る可能性があります。

3. ドメインモデルと性能の妥協を減らせる可能性

value class Money {
    private long cents;

    public Money(long cents) {
        this.cents = cents;
    }

    public long cents() {
        return cents;
    }
}

このような型で意味を保ちながら実行時コストを抑えられれば、実務上の価値は大きいです。

Java 開発者にとって重要な理由

Valhalla が重要なのは、Java が流行語に合わせて変わるからではありません。長期運用、大規模開発、成熟した JVM エコシステムという強みを保ちながら、弱点だった小さな値オブジェクトとメモリレイアウトの問題を減らそうとしているからです。

大規模システムの安定性
+ ドメインモデルの表現力
+ JVM の運用エコシステム
+ 以前より良い値型の性能

注意点と限界

1. JEP 401 はプレビュー段階

JDK 28 をターゲットにした情報はありますが、プレビュー機能である以上、仕様や挙動は変わる可能性があります。本番全面採用ではなく、学習と検証から始めるべきです。

2. ジェネリクスの性能問題が一気に解決するわけではない

JEP 402 は Enhanced Primitive Boxing を扱いますが、現在のジェネリクスが消去ベースである点は残ります。List<int> がすぐ int[] と同等になる、と期待するのは早すぎます。

3. アイデンティティに依存する設計には合わない

• 値オブジェクトを同期対象にしない
• == の意味が変わる
• アイデンティティベースのキャッシュやデータ構造には注意する
• 可変オブジェクトとして考えない

実務で最初に見たい領域

安定後にまず試したいのは、小さく不変で、値そのものに意味がある型です。

Money
UserId
OrderId
Coordinate
TimeRange
Version
EventTime
MetricPoint

イベント処理、ログ集計、メトリクス、座標、財務計算などでは、多数の小さなデータが流れます。ここでは割り当てレート、メモリフットプリント、GC を JMH などで測り、効果をデータで見る必要があります。

結論

Project Valhalla は、長年 Java を使ってきた開発者として素直に期待したい変更です。Java を Rust や Go に変えるものではありませんが、Java のまま性能上の妥協を減らす方向性があります。

同時に、過度な期待は禁物です。プレビュー機能であり、ジェネリクスや全コードパスの性能が一気に解決するわけではありません。それでも、Java が過去の選択肢ではなく改善を続けるプラットフォームであることを示す動きとして、Valhalla は十分に注目に値します。

FAQ

Project Valhalla は JDK 28 で確定ですか？

JEP 401 は JDK 28 をターゲットにしたプレビューとして扱われていますが、プレビューである以上、最終仕様や使い方は変わる可能性があります。

Valhalla で Java は Go や Rust と同じになりますか？

いいえ。Valhalla は Java の弱点を減らす取り組みであり、別の言語のデプロイモデルや所有権モデルを取り込むものではありません。

record と value class の違いは？

record はデータキャリアを簡潔に書く機能です。通常の record はアイデンティティを持ちます。value class / value record はアイデンティティのない値オブジェクトを目指します。

関連記事

参考文献

• OpenJDK Project Valhalla
• JEP 401: Value Classes and Objects (Preview)
• JEP 402: Enhanced Primitive Boxing (Preview)
• State of Valhalla: Part 1
• State of Valhalla: Part 2
• State of Valhalla: Part 3
• JVM Weekly, Project Valhalla Explained

韓国語原文