Project Valhalla，详解：十年的工作如何在 JDK 28 中到来

原文 ↗ Hacker News 讨论 ↗

Project Valhalla 的范围和目标

  • 线程参与者一致认为，Valhalla 的主要目标是：
    • 没有身份的值类。
    • 更紧凑、扁平化的布局（尤其是数组）。
    • 将现有类型（例如像 Integer 这样的包装类）改造为值类，而无需源代码更改。
  • 许多人强调，在一个已有 30 年历史的生态系统中，以 向后兼容 的方式做到这一点，比在一个新的运行时里直接设计结构体要困难得多。

与 .NET、C# 和其他语言的比较

  • 反复拿它与 C# 的 struct 和 reified generics 作比较：
    • 有些人说 Java 只是“在追赶” .NET 早已具备的功能，文章把新颖性说得过头了。
    • 另一些人则认为，.NET 面临的历史包袱更少；在保持旧二进制继续运行的同时把这些能力加到 JVM 上，并不简单。
  • 关于 fibers/虚拟线程与 async/await 的争论：
    • 有些人认为虚拟线程明显优于带颜色的 async 函数。
    • 也有人指出它们各有取舍，并不能普遍认为“客观上更好”。

可空性与类型系统争论

  • 对 Java 缺乏内建空安全的分歧很大：
    • 有些人认为 Valhalla 错失了在类型层面修复 null 的机会。
    • 另一些人指出，已经有关于空限制类型（T!）的草案 JEP，以及更粗粒度的“这里全部非空”上下文计划。
  • 关于空可空性应该是类型的属性还是变量的属性，也存在争议。
  • 还拿 Kotlin、C#、Hack、Go，以及 Rust 的做法作比较；对“正确模型”并没有共识。

语义：身份、相等性与封装

  • 值类没有身份；== 变成按位/状态比较：
    • 有些人欢迎这一点；另一些人担心它会泄露内部表示（例如不同的未规范化分数形式比较为不相等）。
  • Integer/Long/Double 变成值类：
    • 这被认为是少见的破坏性变更：依赖引用身份或奇特装箱行为的现有代码可能会改变或失败。
  • 还澄清了值类的设计意图是不可变的（字段实际上是 final）。

性能、扁平化限制与 tearing

  • 当前预览只会扁平化那些元素表示（包括 null 标志）能放进平台原子写入大小的值数组（通常是 64 位）：
    • 怀疑者说，这会让收益主要局限于小类型和装箱原语。
    • 支持者则指出，未来还有空限制类型、“可 tearing”语义等工作，而且局部变量的标量化仍然有用。
  • 有人担心标量化/扁平化会以不透明的方式失败，使性能表现不可预测；一些人更希望编译期报错，而不是静默退回堆分配。

Java 的演进与治理

  • 观点明显分裂：
    • 批评者指责 Java 过于保守、错失机会（空安全、泛型设计），并且过于复杂。
    • 辩护者强调持续且快速的渐进改进（GC、虚拟线程、record、sealed types）、强大的向后兼容性，并认为尽管 HN 持怀疑态度，Java 的状态比以往任何时候都更好。

元话题：文章质量

  • 多位评论者批评：
    • 文风和配图看起来像是 AI 生成的。
    • 存在技术不准确之处（硬件历史、忽略 64 位限制的示例）。
  • 有人说，即使底层 JEP 本身没问题，这也削弱了人们对该解释文章的信任。