为什么Java8是可选的实现为最终的，没有一些和没有层次结构？

Question

在Java中，optional被实现为公共final类optional {...} 而不是some和none的密封层次结构。

为什么这里不是这样？这是Java中缺少sealed的解决方案吗？背后有没有更深层次的推理？

public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
    Objects.requireNonNull(mapper);
    if (!isPresent())
        return empty();
    else {
        return Optional.ofNullable(mapper.apply(value));
    }
}

它们不仅很难看，而且如果有更长的方法链，ispresent将需要在每次调用期间计算，即使optional从一开始就为空。

如果我们可以向下传递一个固定的实现，就可以避免这种情况。

optional
  .map(i -> i) // isPresent()
  .map(Object::toString) // isPresent()
  .map(String::length) // isPresent()
  .map(...) // isPresent()

为什么不使用子类型来建模空和非空的情况？

Answer 1

class optional上的final修饰符是为了准备一个更大的特性：值类型，这是Project Valhalla的目标（Java10+的特性）。

您可以在下面链接的2014年文章中阅读关于Java的值类型的所有内容：

JEP169起草了将值对象实现到Java中的建议。

基元类的设计和实现已经足够成熟，我们可以很有信心地预期将Java平台的某些类迁移成未来版本中的基元类。

在2014年的论文中，提到了基于值的类如何充当值类型的盒装版本：

实际上，每个值类型的装箱形式似乎都是一个基于值的类。

但是，理论上，并不是所有的对象都需要标识，正如上面链接的2014年论文中明确提到的：

对象标识仅用于支持可变性，在这种情况下，对象的状态可以发生变化，但保持相同的内在对象。

标识不是自由的，不可变类型不需要变异，这就意味着它们不需要标识。

对象标识具有占用空间和性能成本，这是Java与其他许多面向对象语言不同的一个主要原因，它具有原语。

James Gosling早在1999年就写过一篇关于将不可变类型编译为值的文章：

在当前的语言规范下，一个足够聪明的优化编译器几乎有可能将某些类转换成不是堆分配的、通过值而不是引用传递的轻量级对象：声明类及其所有实例变量为final。

2014年关于Java中的值类型的论文进一步公开了强制执行final要求的决定：

值可以参与基于继承的子类型吗？没有。

值类可以是抽象的还是非final的？没有。

值类型不能参与传统的子类型（如果有的话，那将是有限的）。