甲骨文一直在努力向Java中加入值类型，这项工作包含在Valhalla项目中，Valhalla是“一个探索和孵化候选高级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