Java值类型的当前状态(5)

发布于2019-04-21 20:28:26

甲骨文一直在努力向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