JDK-5101827 : Adding a Copyable interface to java.lang
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2004-09-14
  • Updated: 2017-05-11
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: rmT116609			Date: 09/14/2004


A DESCRIPTION OF THE REQUEST :
Currently the standard Java way to create a copy of an instance is by invoking the clone method. As previous bug reports show, this method is by many developers considered hard to use because it throws a checked exception which forces you to surround your code with try and catch statements.

Further more, you can almost always be sure that invoking the clone method will not throw an exception - still, Java forces you to write try and catch statements.

An earlier bug report requesting that the clone method should be changed to throw an unchecked runtime exception instead have been rejected as being too disruptive. See bug 4220218.

As a result many developers avoid using the clone method which results in many different practices for copying an instance. Some developers implement their own copy method which creates a clone without throwing an exception and others create constructers which accept an existing instance as an argument  and returns a copy.

  To standardize the way we, the Java developers, create instance copies I suggest introducing a java.lang.Copyable interface similar to this:

interface Copyable<T> {
  T copy();
}

This interface can then be implemented by all classes which support copying. Consequently, if a class A implements Copyable<A> it is now possible to create a copy of a using the following line of code:

A a = anExistingInstanceOfA.copy();



JUSTIFICATION :
Currently the only standard alternative is to write the following:

try {
  A a = anExistingInstanceOfA.clone();
}
catch(CloneNotSupportedException exception) {
  //this should never happen since A supports cloning
  assert false;
}
(Incident Review ID: 310640) 
======================================================================

Comments
It might be slightly better to have: interface Copyable<C extends Copyable<C>> { C copy(); }
07-02-2017

EVALUATION A SDN reader writes: "There's no reason not to implement this with the introduction of generics and covariant return types. Years of examination have not revealed a superior alternative because prior to 1.5.0 one likely did not exist. Now there is a clearly superior alternative: Copyable. It's polymorphic, easy to use and with covariant return types a subclass can specify a more specific type than a superclass. A typical implementation of Copyable could use a "copy constructor", i.e. a constructor that takes an existing instance of the class and duplicates its state. It would be trivially easy for a subclass to then override copyable() and use its own copy constructor which calls the superclass's copy constructor. It achieves everything Cloneable does, only it doesn't require checked exceptions, doesn't have all the problems associated with Cloneable and is less likely to result in bugs due to variables being cloned when they should be initialized instead. Furthermore, we've been using this exact interface for some time now and it has proven flexible, reliable and far superior to Cloneable. In fact, I only discovered this RFE because I was checking to see if one already existed before I submitted it."
23-09-2006

EVALUATION The Cloneable interface is not perfect, but years of examination has not revealed a clearly superior alternative. One worries that another attempt to fix this would introduce more confusion and thus not be worth it. Nevertheless, it is worth examining again such a new interface, especially if we can leverage the generics addition to the language, as proposed. ###@###.### 2004-09-15
15-09-2004