JEP 401 Value Objects (Preview) 已合併至 OpenJDK master

概述

JEP 401 Value Objects (Preview) 與 JEP 539 Strict Field Initialization 已合併至 OpenJDK master 分支。該 Pull Request #31120 整合了 2,934 個 commits，包含 208,011 個新增與 13,161 個刪除，共同實現了 JEP 401 的首次預覽以及其依賴的 JEP 539。在解決合併衝突並獲得所需核准後，該變更於 2026 年 7 月 31 日準備好進行整合。所有產生的程式碼應在 valhalla/lworld 倉庫中進一步開發，該倉庫與 jdk/master 每週同步標籤。

語言實現

Java 語言現在允許宣告定義不可變且無身份（identity-free）類型的 value classes。此變更對應於子審查 JDK-8317277 (Java language implementation of value objects)。Value classes 可作為泛型類型的類型參數，例如 List<T> 和 Comparable<T>。正如一位評論者所指出的：「泛型類型如 List<T> 和 Comparable<T> 可以使用 value classes 作為類型參數進行實例化。JEP 218, Generics over Primitive Types (with revisions)，將允許泛型類別與方法在以 value class 類型參數化時，針對欄位、陣列與區域變數佈局進行特化。這太酷了！JVM 需要更多方式來利用編譯時已知的數值大小，以實現更好的記憶體配置與優化。」目前的預覽版本尚未包含 JEP 218 所承諾的特化功能，這仍是未來的步驟。

JVM 實現

JVM 已進行更新，以便在不使用傳統物件標頭（object headers）的情況下配置 value objects，並強制執行 JEP 539 所預覽的嚴格欄位初始化（strict field initialization）。這項工作由子審查 JDK-8317278 (JVM implementation of value objects) 追蹤。JVM 現在將 value objects 視為 inline types，移除了物件身份及相關的標頭開銷。一位評論者對其影響提出了疑問：「如果我理解正確，那麼 Integer 會變成一個 value class，且它的每個實例都會失去其物件身份。我對細節了解不多，但從一開始來看，這對我來說似乎是一個相當大膽的舉動。」另一位則詢問數據限制：「最新進度如何？是否仍限制在 63 位元數據加上 1 位元用於可空性（nullability）？」這些問題反映了該功能的預覽性質。

標準函式庫更新

核心函式庫的調整在保留 String 等類別現有引用類型（reference types）的同時，也適應了 value objects。子審查 JDK-8317279 (Standard library implementation of value objects) 更新了 JDK 以與 value types 協作。一位社群成員觀察到兩者之間仍存在的區別：「真的很酷，遺憾的是字串儘管具有不可變性，卻無法像 Integer 那樣完全無法區分。」同時，另一位對此進展表示讚賞：「現代 Java 簡直太棒了。我真的無法理解現在除了 OG 之外還會用別的！」

與 JEP 539 的關係

JEP 401 依賴於 JEP 539 對嚴格欄位初始化的預覽，以確保 value object 的欄位在使用前已完全初始化。 Pull Request 描述明確指出，JEP 539 是在同一個程式碼庫中實現的，因為 JEP 401 依賴於嚴格欄位初始化。原始資料中沒有關於此依賴關係的進一步評論。

社群反應

Hacker News 的評論者對此次合併表示歡迎，認為這是效能里程碑，同時討論了其範圍以及與更廣泛的 Valhalla 計畫的關係。

我對此深有同感：我非常熱愛 Java 這門語言。缺乏 value types 是實現某些類型效能的最大障礙。我非常期待這門語言的演進。 – @timmg 我認為理解這項功能涵蓋了什麼與沒涵蓋什麼非常重要。這「僅僅是 Valhalla 的第一部分」。例如，可以參考 https://www.jvm-weekly.com/p/project-valhalla-explained-how-... 的優秀總結 – @mormegil 我一直對 Java 領導層在推出推動語言前進的變更時，同時盡可能保持向後兼容所投入的思考與工作感到驚訝。 – @ludovicianul 現代 Java 簡直太棒了。我真的無法理解現在除了 OG 之外還會用別的！ – @exabrial 終於看到這裡有進展了，這真的很棒。缺乏 value types 在這幾十年來一直是 Java 最大的效能陷阱之一 – @swiftcoder 有趣的是，雖然兩門語言都在接收新功能，但 Java 似乎領先於 JavaScript：- Java 早已有了 Date 的現代替代方案，而 JavaScript 最近標準化的 Temporal API 在 Safari 中仍不受支援。- Java 有 switch expressions，而 JavaScript 儘管受到 Scheme 的影響，卻沒有。- 現在 Java 正在獲得 value objects，而 JavaScript 對應的 tuples & records 提案已被撤回。 – @sheept 泛型類型如 List<T> 和 Comparable<T> 可以使用 value classes 作為類型參數進行實例化。JEP 218, Generics over Primitive Types (with revisions)，將允許泛型類別與方法在以 value class 類型參數化時，針對欄位、陣列與區域變數佈局進行特化。這太酷了！JVM 需要更多方式來利用編譯時已知的數值大小，以實現更好的記憶體配置與優化。 – @ivanjermakov 如果我理解正確，那麼 Integer 會變成一個 value class，且它的每個實例都會失去其物件身份。我對細節了解不多，但從一開始來看，這對我來說似乎是一個相當大膽的舉動。 – @weinzierl 之前關於 project Valhalla 的 HN 討論：https://news.ycombinator.com/item?id=48595511 – @kuhsaft 我一直忘記這個設計部分的理由——為什麼 value semantics 是在宣告處（declaration site）而非使用處（use site）內建的？為什麼類別作者必須將其宣告為 value type？我知道 Brian 已經反覆討論過很多次了，但我就是會忘記理由。 – @swaranga 太棒了，儘管特化的泛型（specialized generics）仍然缺失。我認為這些改進對 Scala 特別有益，因為它是一門如此強大的語言，但在 JVM 上進行抽象是有沉重代價的。 – @pregnenolone 2934 個 commits，天啊... 巨大的工作量。 – @germandiago Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability – @parallax_error 最新進度如何？是否仍限制在 63 位元數據加上 1 位元用於可空性？ – @HexDecOctBin MR 已關閉，就是這個 https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842... – @ligarota 這佔 Valhalla 的多少比例？50%？90%？ – @whytevuhuni 收藏以備後用 – @hn4yci687u