Why is #clone() not in the Cloneable interface?

Question

I was reading up on performing a deep-copy of an array correctly, however I was confused about how the #clone() is implemented. It is a member of the java.lang.Object class, and yet if you read the javadocs:

First, if the class of this object does not implement the interface Cloneable, then a CloneNotSupportedException is thrown.

So why define the clone method there in the first place? Surely if a method can only be used when an interface is present, you'd put the method in the interface. The Cloneable interface itself is empty; it is just a marker interface used by Java to ensure that using the clone method is legal.

Doing it this way also removes the ability to make use of generics to ensure type safety:

class Foo implements Cloneable { // Valid.
    @Override
    public Object clone() throws CloneNotSupportedException {
        // ...
    }
}

class TypeSafeFoo implements Cloneable<TypeSafeFoo> { // Not valid.
    @Override
    public TypeSafeFoo clone() throws CloneNotSupportedException {
        // ...
    }
}

Why has Java done it this way? I'm sure they have legitimate reasons, but I can't seem to figure it out.

Answer 1

The cloning contract in Java dictates that each clone implementation must first obtain the cloned instance from super.clone(). This creates a chain that always ends with the call to Object.clone, and that method contains "magical" native-level code that makes a binary copy of the underlying raw struct which represents the Java object. If this mechanism didn't exist, clone would fail to be polymorphic: the Object.clone method produces an instance of whatever class it is called on; this cannot be reproduced without native code.

This is why the Object.clone method could not have been avoided. Cloneable could have contained a clone method, but it would create issues regarding the throws clause. The way it stands you are free to declare clone with no declared exceptions, or to declare arbitrary exceptions. This flexibility would not be possible if the method was already declared in the interface.

Bear in mind that Generics would be of little use for cloning: imagine protected T clone() in Object: where would T come from? Would we need Object<T> and force each and every class in Java universe to be parameterized on itself, and all this just to make this semi-deprecated mechanism work a tiny bit better? Keep also in mind that this code is perfectly legal:

public class TheMightyOne implements Cloneable {
   @Override public TheMightyOne clone() {
     return (TheMightyOne) super.clone();
   }
}

You can call it:

TheMightyOne one = new TheMightyOne();
TheMightyOne two = one.clone(); // do downcasts needed

Answer 2

To deal with creating the clone and basic field copying, clone needs to inherit a method implementation. A Cloneable class can appear anywhere in the hierarchy, and may need to extend a specific superclass to do its primary job. The only superclass from which all possible Cloneable classes can inherit implementation is Object.

Cloning was defined long before generics.