JEP 401：值对象（预览）合并到 OpenJDK master

Project Valhalla 与 JEP 401 范围

• JEP 401（值对象，预览）已合并；被视为 Project Valhalla 的第一阶段、也是至关重要的一半（大致约为愿景的“~50%”）。
• 剩余工作包括专用泛型、SIMD/向量 API、可具化泛型，以及不可为 null 的类型。
• 许多评论者表示，仅这一项就已经让 Valhalla 成功了，尤其是在性能方面。

值对象：语义与性能

• 值对象被描述为“类似结构体”：没有身份、不可变、在可能时可扁平化，并带来显著的内存与缓存收益。
• 设计强调“默认保证完整性”：安全语义和强保证优先，性能选项则作为明确的显式选择。
• 一种设计划分把数据分成四类：经典对象、无身份对象、原子值，以及可撕裂（“经典”）值。

Integer、身份与字符串

• Integer 和类似包装类型将变为值类，失去对象身份；许多人指出 Integer 由于池化和 hashCode，本来就已经表现得“像值”。
• 依赖 Integer 身份的项目多年来一直有警告；一些小众工具（例如面向 JVM 的语言运行时）可能会受到影响。
• 字符串无法变成完全不可区分的值类型，主要是出于向后兼容和可变长度底层数组的技术限制；而且收益本来也被认为有限。

原子性、可撕裂性与大小限制

• 讨论集中在原子性上：值类必须不能“撕裂”，除非显式标记为可撕裂。
• 当前模型把引用扁平化与机器字大小绑定（例如 63 位 + null 位）；更大的值可以存在，但不能以同样方式扁平化。
• 有人认为其他平台（例如 .NET、支持 128 位原子操作的 CPU）展示了不同取舍；也有人强调 Java 的内存模型和安全保证决定了设计。

向后兼容与迁移

• 大家非常认可 Java 的长期稳定性：旧代码通常无需修改即可运行；破坏性变更很少、会被明确标注，而且范围很窄。
• 例如：对 Integer 实例加锁在它们变成值对象后最终会失效。
• 值语义是在声明处定义，而不是在使用处定义，以确保可由类本身强制执行不可变性和安全性。

OpenJDK 流程与治理

• 这个 PR 通过一个 bot 把成千上万次提交压缩成一个；详细历史保存在单独的工具中，而不是 Git 里。
• 有人不喜欢这种“被销毁”的 Git 历史；也有人认为这一流程是有意为之，目的是避免 GitHub 锁定并保持外部工具可移植。
• 据说 Valhalla 的工作几乎完全由 Oracle 主导；与典型的“先发货再说”文化相比，这种纪律性和长期愿景受到称赞。

对生态系统的影响

• 预计这会显著提升 Java 以及更高层 JVM 语言（如 Scala）的性能，尤其是在今天抽象代价很高的场景中。
• 值类型上的泛型和更好的布局专门化被强调为未来的重要收益。

Java 语言、文化与对比

• 许多人对现代 Java 表现出强烈热情：records、lambdas、streams、虚拟线程、结构化并发，如今又有值对象。
• 有几位认为 Java 的演进比 C# 更清晰（在一些人看来 C# 过于复杂），并保持了更简单的模型（值 vs 引用 + Valhalla）。
• 持续的批评集中在“企业文化”上：啰嗦的框架（尤其是 Spring）、冗长的类名以及庞大的代码库；而另一些人反驳说这更多是文化问题，而非 Java 本身的问题。
• 也有人提到更轻量的框架（如 Helidon、Quarkus）以及以虚拟线程为中心的设计。
• Java 还反复被拿来与 JavaScript 对比：表面语法相似，但目标完全不同；Java 被认为在现代日期/时间、switch 表达式以及现在的值对象等特性上更领先。

工具与 CLI

• 有人希望有一个更像 Go 那样“开箱即用”的统一 CLI，用于 build/test/format/lsp，而不是当前的碎片化状态（Maven、Gradle 等）。
• Maven 因稳定性受到欣赏，但其 XML 和升级模型受到批评；Gradle 被认为功能强大，但对版本较敏感。