java - Cloneable#clone 方法不必要的转换

Question

class MyCls implements Cloneable {
  @Override
  protected MyCls clone() throws CloneNotSupportedException {
    return new MyCls(//...
  }
}

上面的代码没有任何问题。那么为什么 CopyOnWriteArrayList#clone 返回一个 Object 而不是 CopyOnWriteArrayList？从 Object 转换回所需类型时，编译器会报错。这个设计决定的最终原因可能是什么？我看到这种模式在图书馆各处重复出现。

Ralph建议以下代码有效，而不是上面的代码:

@Override MyCls clone() throws CloneNotSupportedException { 
  MyCls clone = (MyCls)super.clone();
  clone.x = this.x; //or what ever to do return clone
  // ...
}

问题还是一样。为什么 CopyOnWriteArrayList#clone 返回 Object 而不是它自己？

Answer 1

您的问题基于 covariant return types ，即能够覆盖具有更具体返回类型的方法。

此功能在 Java 中并不总是存在。更准确地说，它是在 Java 5 中引入的，该版本还引入了并发工具，包括 CopyOnWriteArrayList。

但这并不是说先开发语言更新，然后再开发类。这些类经历了在 Java 5 和更早版本之前开始的开发过程，可以从 http://gee.cs.oswego.edu/dl/concurrency-interest/ 下载草稿

因此，早期版本必须声明与覆盖方法相同的返回类型，当它们与 Java 5 一起发布时，没有人及时考虑更改方法以利用协变返回类型。显然仍然没有负责人考虑它。它可能不够重要。

这不是一个独特的情况。

NIO Buffer API 是在 JDK 1.4 中引入的，在协变返回类型成为可能之前的一个版本，直到 Java 9，才添加了具有更具体返回类型的覆盖(例如 ByteBuffer.position(int) 、 limit(int) 或 clear() ；与具有的 the Java 8 version 相比只有继承的版本阻碍了 API 的流畅使用)。

但请注意，在类发布后更改方法以利用协变返回类型，can create compatibility problems 当您在比预期运行的新 JDK 版本下编译代码时。解决方案 the --release option 也晚于 JDK 9 引入。