Question

The Java specification for the java.lang.Cloneable interface defines itself as signifying that any object that extends it also has implemented the clone() method that rests dormant within java.lang.Object. Specifically, it says that:

A class implements the Cloneable interface to indicate to the java.lang.Object#clone() method that it is legal for that method to make a field-for-field copy of instances of that class.

To me, this means that it should be assumed that every class that extends Cloneable therefore also has a public Object clone() method within it. This makes it easy to assume that the following is a valid method:

public static makeACloneFrom(Cloneable c)
{
  return c.clone();
}

however, this is not the case, as the entirety of the Cloneable source code (sans javadoc) is simply

package java.lang;

public interface Cloneable {
}

Which means that Cloneable#clone() does not exist (and trying to compile the example method above throws a compile-time error saying something like “cannot find symbol: method clone()“). Shouldn’t the source code of Cloneable contain something to the effect of public Cloneable clone();?

Why aren’t we allowed to assume that a class that implements Cloneable has a public Cloneable clone() method?

Answer 1

Because it’s a poorly-designed interface.

From Effective Java (sorry, Google Books does not have a preview for the 2nd edition):

Item 11: Override clone judiciously

The Cloneable interface was intended as a mixin interface (Item
18) for objects to advertise that they permit cloning. Unfortunately,
it fails to serve this purpose. Its primary flaw is that it lacks a
clone method, and Object‘s clone method is protected. You
cannot, with resorting to reflection (Item 53), invoke the clone
method on an object merely because it implements Cloneable. Even a
reflective invocation may fail, as there is no guarantee that the
object has an accessible clone method.