JDK-7029334 : Deprecate clone() and Cloneable
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2011-03-21
  • Updated: 2017-05-11
  • Resolved: 2012-07-23
Related Reports
Relates :  
The clone-method has no benefits over a copy-constructor and some severe drawbacks. You can *allways* implement clone() with a copy-constructor by simply calling it in the clone-method on yourself for the new object, but you cant do it vice versa, because clone() doesnt work on an object (something like a.cloneTo(Object b) would at least have some use), but instead returns a freshly created object of an already set class.

The following can be easily implemented if copy-constructors have been used by the superclasses, but it is not implementable without simulating the copy-constructor of the superclass in your derived class:

class derived1 extends base;
class derived2 extends base;

derived1 a = new derived1();
derived2 b = new derived2(a);

Either change to a.cloneTo(Cloneable b), whitch would also have some benefits over a copy-constructor, or remove it (after a reasonable deprecation tme) completely from the language.
The clone()-Method gives you a clone, whitch is nice if you want a clone. But it let also to tons of java-code without a copy-constructor ��� and that is a huge drawback for the language at all.

---------- BEGIN SOURCE ----------
---------- END SOURCE ----------


We may want to reconsider this at some point. (notes from Jan 2016 with Joe Darcy and Jon Gibbons) Many things in the JDK are Cloneable; doing this would generate a lot of warnings. Since most uses are classes that implement Cloneable, the only way to suppress is to put @SW on the entire class. This seems too broad. Alternatives: allow @SW at the point of use within ���implements��� (target TYPE_USE); or have a @SW tag string that���s specific to Cloneable; or invent some mechanism to suppress warnings caused by a particular deprecation. Adding TYPE_USE allows use in a bunch of other places that probably don't make sense. We could add a CloneableNoWarning interface that's not deprecated, and adjust all Cloneable things to implement CloneableNoWarning. Deprecation isn't inherited, so this would effectively disable deprecation warnings for internal use. Also, overrides of clone() presumably wouldn't be deprecated either, so their use wouldn't generate a warning (but there would be a warning at the override itself). @SuppressWarnings could be added at the package level (in package-info.java) to suppress a particular kind of warning within all source files of this package. Currently, @SW in a package-info.java is allowed but explicitly has no effect.

EVALUATION The Cloneable interface and clone method are an admittedly less than ideal mechansim, but they are not going to be deprecated. Closing as will not fix.