ついに本命が来る！Javaに革命をもたらす「Project Valhalla」がJDK 28で実現するまで

10年越しの悲願がついに達成へ。Javaの進化を根本から変える「Project Valhalla」が、JDK 28でいよいよ実装される見通しとなりました。本稿では、なぜこのプロジェクトがJava開発者にとって極めて重要なのか、そしてメモリレイアウトやパフォーマンスにどのような革命をもたらすのかを分かりやすく解説します。

JavaにおけるValue Types（値型）の進化をテーマにした技術スリラーでも書けそうだな。メーリングリストを読んだり関連動画を全部見たけど、あのJavaらしさを保ちつつデザインをまとめ上げた手腕は本当に感銘を受けるよ。Value Typeとは一体何なのか、どこでどんな最適化ができるのかという粒度の深い部分まで踏み込んでいるのがすごい。

Valhallaに最終的に盛り込まれた機能への努力には敬意を表するよ。でもね、「モデルは強力だが精神的負荷も高い」というのは違う！そんな解釈がnull安全性に関する議論を完全に殺しているんだ。nullになれない変数を持つこと自体は、決して難しい概念じゃない。ちゃんとラベル付けされていればね。「ユーザーのためにモデルを簡素化する、たとえパフォーマンスの上限を犠牲にしても」という方針で二元性を排除したようだけど、それはユーザーにとっての簡素化にはならないよ。言語の型システムって、数値を扱うだけのCPUの上で、開発者に便利な保証を与えるためのものだろ。「精神的負荷が高い」なんて理由で、本来提供できたはずの安全性を削るなんて納得いかない。言語モデルとJVMモデルが完全に一致しなくてもいいと認めてるんだから、もっとうまくやれたはずだよ。

.NETの存在を認めるのはJava界隈ではタブーだけど、これって.NETのstructと何が違うの？Value typesにジェネリックの特殊化、ボックス化…。ざっと見た感じだと、同じ道を選んだように見えるけど。

「==は内部状態を見るから、同じデータか確認するにはequalsを使い続けろ」だって？じゃあValueクラスの==は実質的にmemcmp()みたいなものか。カプセル化を破壊して実装の詳細を露呈させることになるから、これはちょっと残念だね。クライアントコード側で、値がどう内部的に表現されているかによって条件分岐するような使い方もできてしまう。ID比較なら内部状態を見せない分、まだマシだったのに。

ここのコメントの多くは、行われている素晴らしい仕事や、今後パイプラインにあるJEPに対してちょっと不当だと思うな。Javaを子供に例えるなら、Sunという愛情深い両親に育てられた後、Oracleという邪悪な保護者にガレージに放置されてネグレクトされたようなものさ。JDK 8まではずっと後追いばかりさせられていた。だから「ようやく構造体や値型が来たのか」なんて言われるけど、それは官僚的で敵対的な企業プロセスに成長を阻害されていたからであって、今はOpenJDKファミリーのおかげで本来の愛を受けているんだ。これからも「一度書けばどこでも動く」Javaを楽しませてもらうよ！

「メモリの違いは決定的だ。JVMは配列の中に値を直接、隙間なく連続して配置できる」…この記事、校正したのか？64ビットを超えるオブジェクトにはヒープフラット化が効かないって話をした直後だろ。Pointは少なくとも65ビット（32ビット整数2つ＋nullフラグ）あるし。「nullフラグの可能性」とかその後の短すぎる文とか、AIが無理やり力説しようとして脱線したように見えるな。途中に挿入されてる[IMAGE: ...]のブロックも酷いもんだ。

脚注6の「C#のstructと何が違うのか」という説明は不正確だね。記事全体がAI生成画像だらけだし、執筆や調査もハルシネーション（幻覚）だらけなんだろうな。

少しあやふやでドラマチックすぎるね。幸いなことに元のドキュメントはかなり読みやすいよ。C#、Swift、Java、Rustはみんなハードウェアに追いつこうと競い合っていて、お互いに影響を与え合っていると思うから、誰かがそれぞれの開発の変遷を追いかけてくれると面白いんだけどね。FFIのメモリ共有にどう影響するかが個人的には一番の懸念点かな。

ここのコメントを読んでいて思うのは、HNのJava/JVM関連スレで繰り返される定番のパターンがあるってこと。「JVMやJavaが昔どうだったか」というイメージだけで語る人が驚くほど多いけど、今の実態をあまり知らないんだよね。2026年の今、Javaは非常に強力なプレデターだよ。欠点がないとは言わないけど、土台はめちゃくちゃ優秀なんだ。

値クラスの意図はわかるけど、実装には欠陥があると思う。このコードがどう出力されるか考えてみて。これまでなら答えは自明だったけど、値クラスの追加で、Pointが値クラスか参照クラスかによって答えが変わってしまう。これじゃあ可読性が落ちるよね。「統一性の原理」に違反しているよ。Weinbergの『コンピュータプログラミングの心理学』にもある通り、人間は似た見た目のものは似た挙動をするはずだと期待するものさ。言語側で、見た目はほぼ同じなのに意味論が大きく異なる構成を許せば、読者の認知負荷は増大するだけ。代入や平等性、可変性がどう振る舞うかを宣言を確認しないとわからないようでは、コードの推論と保守が難しくなるよ。宣言時だけでなく使用時にもvalueキーワードを必須にするようにすれば、この問題は解決できたはずなのに。