Java 值类型的当前状态

甲骨文一直在努力向 Java 中加入值类型，这项工作包含在 Valhalla 项目中，Valhalla 是“一个探索和孵化候选高级 Java 虚拟机和语言特性的地方”。InfoQ 之前已经报道了这个项目以及向Java 中引入值类型的工作进展。

值类型旨在成为未来 Java 版本中的第三种数据类型，当前已有的两种类型分别是原始类型和对象引用。经常有人说，Java 值类型应该“写起来像类，用起来像 int”。这意味着它们应该是一个复合数据类型（代码与类相似），只是少了标识，并且如果有可能的话不提供对象头部（像 int 一样）。

以 Java 平台目前的情况来看，运行环境不会提供这种对内存布局的底层控制形式——它可能类似于 C 语言当中的 struct，但 JVM 并不支持。所以，在当前版本中，所有组合数据类型都必须通过引用来访问。

如果要将 Java 平台扩展为包含值类型，那么自然会产生这样的问题：值类型是否可用作类型参数（type parameter）值。如果不是，那么这似乎大大限制了它们的用处。因此，值类型的设计一直包含这样的假设，即在增强的泛型中，值类型可以作为类型参数的值。

这与 Java 类型系统缺少顶级类型（top type）有关——Object 和 int 不存在共同的超类型。换句话说，Java 类型系统不是单根（single-rooted）的。由于这个原因，Java 泛型类型的类型参数只能是引用类型。如果可能引入值类型，那么就必须解决这个问题（并且还要考虑泛型的类型擦除）。

从 Java 8 开始，其设计目标之一就是提高 JDK 中某些引用类型可能会在后续版本中发展成为值类型的可能性，所以这也是需要考虑的一个设计约束。两个明显的候选例子是 Optional 和 LocalDateTime——它们都具有值类型所期望的属性。例如，它们都是不可变的，并且都具备了值类型语义，即当且仅当所有字段的值都相等时，两个对象才相等。

如果 JDK 类型有可能演变为值类型，那么问题来了：值类型在类文件中应该怎样表示？在当前版本的 JVM 中，引用类型为 L<qualified type>;，所以 Optional 使用描述符 Ljava/util/Optional; 来表示。在过去的几年中，为了确定在类文件中如何表示值类型，开发者们已经评审过不同的提案和设计方案。

甲骨文 JVM 架构师 John Rose 最近简要描述了过去的历史、已经尝试过的各种方案以及遇到的问题。

当前的方向继续使用与引用类型相同的描述符语法来描述值类型（而不是像 Qjava/util/Optional; 这样）。这种方法具有保持向后兼容的优点，向后兼容从一开始就是 Java 的首要设计原则。

但是，该设计存在一个问题，因为类型描述符实际上是一种不完整的描述，因为它不区分特定类型是否是真正的值类型。为了解决这个问题，目前的提议是对 JVM 类文件格式进行扩展，增加一个新的片段（ValueTypes），该片段详细说明文件中的哪些类型实际上是值类型。John Rose 已经对此进行了详细的描述，不过 v​​alhalla-dev 邮件列表上仍然在针对一些细节问题进行热烈的讨论。Stephen Colebourne 和其他人最近还讨论了 Java 值类型的可空性（nullability）问题。

与此同时，实现方面的工作进展顺利，预计适用于 JVM 研究者、框架作者和喜欢跟字节码打交道的人的原型将很快推出。通常情况下，对于主要特性，甲骨文不会承诺在任何特定 Java 版本或特定日期交付预期功能。

查看英文原文： The Current State of Java Value Types