不过别抱太大期望——架构师Brian Goetz警告开发者，该特性在下一个长期支持（LTS）版本中可能仍处于预览状态。

Oracle软件工程师Lois Foltan证实，作为Valhalla项目一部分的JEP 401（值类与对象）将于下月初合入OpenJDK主干代码，目标版本为JDK 28。

迄今为止，JEP 401的预览版仅在早期访问（EA）构建版本中提供。

当前的JDK版本为26，JDK 27预计于今年9月发布，JDK 28预计于2027年3月发布。下一个长期支持版本很可能是2027年9月发布的JDK 29。

Foltan表示，这是一次"极其庞大的变更"，因此要求其他OpenJDK提交者避免进行大型代码提交，以确保顺利合入。JEP 401首个预览版的拉取请求（Pull Request）在1816个变更文件中新增了超过19.7万行代码。

JEP 401创建于2022年8月，旨在解决Java长期存在的一个限制：除了int、char、byte和double等少量基本数据类型外，Java语言中的所有类型都是引用类型。该JEP引入了"值对象（value objects）"——即没有对象身份标识（identity），仅通过其字段的值来区分的类实例。

几个例子可以说明JEP 401试图解决的问题。Java的LocalDate类用于存储日期值，但每个实例都会获得自己唯一的引用。因此，即使两个实例代表相同的数据，使用==进行比较也会返回false，因为它们在内存中是不同的对象。LocalDate只能退而提供equals方法来进行比较。

另一个更令人困惑的例子是Integer。它将int包装起来，以提供toString()等便捷方法。在内部，Integer会缓存128以下的值实例，因此两个具有相同较小值的Integer对象可以使用==比较为相等；但对于较大的值，即使底层值匹配，==也始终返回false。由于这一怪癖，Java编辑器通常会警告不要对Integer使用==，JEP 401将这种陷阱描述为"不必要的复杂性"。

JEP 401将把Integer等部分JDK类迁移为值类，并且被迁移的类数量可能会逐渐增加。开发者也将能够创建自己的值类。

JEP 401的目标之一是赋予JVM（Java虚拟机）自由度，使其能够以最大化性能的方式存储值对象。引用类型的内存占用大于值类型，并且必须通过解引用才能获取其值。遍历值类型将更加高效。

由于变更的复杂性，Project Valhalla的开发耗时漫长，以至于一些旁观者开玩笑说，在这个项目交付之前，他们可能已经先到达了"Valhalla"（北欧神话中的英灵殿，死后灵魂归宿）。

Oracle Java语言架构师Brian Goetz表示，这"只是Valhalla项目的第一阶段"。即使在预览版交付之后，"那些认为'他们永远不会交付'的人很快就会转变态度，变成'他们还没交付最重要的部分'"。

Goetz表示："有许多因素迫使我们必须以引用语义来处理对象。JEP 401通过消除对象身份标识，击碎了这些限制的第一层，这暴露出许多新的优化空间，特别是对于较小的对象。但要完全以值语义来处理对象，还需要放弃更多东西：可空性（nullity）以及竞争条件下的原子性安全（ASUR）。许多语言已经拥有或正在开发实现这一目标的方法（例如C#的结构体）。"

"主要的挑战在于，如何将其打包到用户模型中，使其不会与我们对对象完整性和封装性的固有观念发生冲突；无论好坏，类一直是非常有效的抽象屏障。"

他表示，Valhalla将给Java引入一些刻意的破坏性变更，例如"现在对Integer对象进行同步操作将会抛出异常"。

Goetz补充说，JEP 401在JDK的下一个LTS版本中很可能仍处于预览状态。"希望它在JDK 29中退出预览似乎……有些过于乐观了。Vector API应该能在基于Valhalla的底层虚拟机原语进行重构后退出孵化阶段……但不要指望它的预览窗口会比平时短。"