甲骨文一直在努力向 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 最近 简要描述了过去的历史 http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-May/000618.html , 已经尝试过的各种方案以及遇到的问题.
当前的方向继续使用与引用类型相同的描述符语法来描述值类型(而不是像 Qjava/util/Optional; 这样). 这种方法具有保持向后兼容的优点, 向后兼容从一开始就是 Java 的首要设计原则.
但是, 该设计存在一个问题, 因为类型描述符实际上是一种不完整的描述, 因为它不区分特定类型是否是真正的值类型. 为了解决这个问题, 目前的提议是对 JVM 类文件格式进行扩展, 增加一个新的片段 (ValueTypes), 该片段详细说明文件中的哪些类型实际上是值类型. John Rose 已经对此进行了 详细的描述 http://cr.openjdk.java.net/~jrose/values/value-type-hygiene.html , 不过 valhalla-dev 邮件列表 http://mail.openjdk.java.net/mailman/listinfo/valhalla-dev 上仍然在针对一些细节问题进行热烈的讨论. Stephen Colebourne 和其他人最近还讨论了 Java 值类型的可空性(nullability) 问题.
与此同时, 实现方面的工作进展顺利, 预计适用于 JVM 研究者, 框架作者和喜欢跟字节码打交道的人的原型将很快推出. 通常情况下, 对于主要特性, 甲骨文不会承诺在任何特定 Java 版本或特定日期交付预期功能.
来源: http://www.tuicool.com/articles/3QVN3ii