Alex Rivera | Logout

Why is Java's Cloneable Interface Not Generic?

Asked 2008-12-23T08:55:27.897
16

Java 5 introduced generics, and they were added to many interfaces in the java.lang package. However, Cloneable did not get generics. I wonder why?

Edit: In reply to the answers of @Jon and @litb, and the comment of @Earwicker, I was thinking Cloneable might be:

public interface Cloneable<T> {
    public T clone();
}

Here T clone(); overrides Object.clone(), giving it a covariant type. I believe this would still be backwards compatible and increase type safety. So why not?

Edit 2: As can be seen in the answers (and comments) below, the interface suggested above would break backwards-compatibility. Since Object.clone() is protected, rewriting it in the interface would force all implementers to provide a public implementation, which class designers might not want to (i.e. they might opt to keep it protected).

java generics
Edit
Report

2 Answers

21

The Cloneable interface doesn't contain any members. What would be the point of making it generic?

(If Cloneable contained the clone() method, it would make sense - but that's declared in java.lang.Object.)

EDIT: clone() is in java.lang.Object as it has an implementation (which does a field-by-field copy). A better design would be to have something like .NET's MemberwiseClone() as a protected method in Object, and then a public clone() method within the interface itself. I don't know why that design wasn't chosen.

(In .NET, ICloneable isn't generic because it existed before generics - the different nature of .NET generics prevents a previously non-generic type from becoming generic.)

In both Java and .NET, however, the "normal" cloning API is generally regarded as a bad thing, as it says nothing about what depth of cloning should be performed.

answered 2008-12-23T09:00:15.673
1

As a semi-related thought question: would creating an interface (call it ReallyCloneable) that exposes clone() as a public member be useful?

My contention is that no, it wouldn't. Clonability is intimately linked to concrete class implementation. I can't think of a single use case where I'm likely to say "I have an arbitrary object, and I want a copy of it." The immediate question would be: why do you want that copy?

And the typical answer is so that you can modify the copy without affecting the original. However, to do that you need to know what type of object you're holding, otherwise how would you know what to call to modify it? And if you know that, you'll know whether or not it provides a public clone() method.

But what if you're programming to an interface, such as List? Intelligent (recursive) cloning (versus byte-level object data copy) would be incredibly useful with the Collections framework. But there may be collections (such as those backed by a database) that can't support such an operation, so you can't require List to expose a public clone(). Which drives you to instantiating your own concrete List implementation to copy the contents of the source List.

answered 2008-12-23T20:41:31.920

Your Answer