为什么不推荐使用Cloneable？

Question

众所周知，CloneableJava
中的接口已损坏。造成这种情况的原因很多，我将不再赘述。其他人已经做到了。这也是Java架构师本身的立场。

因此，我的问题是：为什么还不被弃用？如果核心Java团队已确定它已损坏，那么他们还必须考虑过时。他们反对这样做的原因是什么（在Java
8中仍不建议弃用）？

Answer 1

有一个错误在1997年提交给Java的错误数据库有关添加clone()方法Cloneable，所以将不再是无用的。它以“无法解决”的决议关闭，理由如下：

Sun的技术审查委员会（TRC）仔细考虑了此问题，建议不要采取 任何措施，除非改进当前Cloneable接口的文档 。这是建议的全文：

现有的Java对象克隆API存在问题。在java.lang.Object上有一个受保护的“克隆”方法，在接口java.lang.Cloneable中也有。目的是，如果一个类希望允许其他人克隆它，则它应该支持Cloneable接口，并使用公共克隆方法覆盖默认的受保护克隆方法。不幸的是，由于时间的推移，人们很容易迷失时间，因此Cloneable接口没有定义克隆方法。

这种组合导致相当多的混乱。一些类声称支持Cloneable，但偶然忘记支持clone方法。对于Cloneable应该如何工作以及克隆应该做什么，开发人员感到困惑。

不幸的是，向Cloneable添加“克隆”方法将是不兼容的更改。它不会破坏二进制兼容性，但是会破坏源兼容性。轶事证据表明，实际上，在许多情况下，类支持Cloneable接口，但无法提供公共克隆方法。经过讨论，TRC一致建议我们不要修改现有的Cloneable接口，因为它会影响兼容性。

另一种建议是添加一个新接口java.lang.PubliclyCloneable以反映Cloneable的原始预期目的。TRC建议以5到2的多数反对。主要担心的是，这将使本来已经很混乱的画面更加混乱（包括拼写混乱！）。

TRC一致建议，我们应该在现有的Cloneable接口中添加其他文档， 以更好地描述其预期用途以及为实现者描述“最佳实践”。

因此，尽管这并不是直接 弃用 ，但不使Cloneable成为“弃用”的原因是技术评论委员会决定 修改现有文档足以
使此接口有用。因此，他们做到了。直到Java 1.4为止，Cloneable文档记录如下：

一个类实现Cloneable接口，以向Object.clone（）方法指示该方法为该类的实例进行逐域复制是合法的。

尝试克隆未实现Cloneable接口的实例会导致抛出CloneNotSupportedException异常。

接口Cloneable不声明任何方法。

从Java 1.4（2002年2月发布）到最新版本（Java 8），它看起来像这样：

一个类实现Cloneable接口，以向Object.clone（）方法指示该方法为该类的实例进行逐域复制是合法的。在未实现Cloneable接口的实例上调用Object的clone方法会导致抛出CloneNotSupportedException异常。

按照约定，实现此接口的类应使用公共方法重写Object.clone（受保护的）。有关重写此方法的详细信息，请参见Object.clone（）。

请注意，此接口不包含clone方法。因此，仅凭对象实现此接口的事实就不可能克隆对象。即使克隆方法是反射式调用的，也不能保证它会成功。