Java: Rationale of the Cloneable interface

Question

Why wasn't the .clone() method specified in the java.lang.Cloneable interface ?

Tzong

Answer 1

Basically, it's a broken interface. Ken Arnold and Bill Venners discussed it in Java Design Issues.

Arnold:

If I were to be God at this point, and many people are probably glad I am not, I would say deprecate Cloneable and have a Copyable, because Cloneable has problems. Besides the fact that it's misspelled, Cloneable doesn't contain the clone method. That means you can't test if something is an instance of Cloneable, cast it to Cloneable, and invoke clone. You have to use reflection again, which is awful. That is only one problem, but one I'd certainly solve.

Mount

Why wasn't it fixed in Java 8? Haven't broken/ineffective parts of Java been removed/changed before? – Wye

It's "broken" because a few people say so? "Cloneable doesn't contain the clone method" Yes, and its documentation never said it would. "That means you can't test if something is an instance of Cloneable, cast it to Cloneable, and invoke clone." Again, that's not the purpose of Cloneable at all. Cloneable is just to make Object.clone() throw an exception or not. It has never been an interface for you to invoke clone. Maybe it would be nice if Java had such an interface, but lack of one does not make another interface (Cloneable) broken. – Bramble

@Bramble Just because its behavior matches its documentation doesn't make it a good interface. I guess if your code doesn't work you just change the documentation? – Mount

Answer 2

See this bug in the Java bugs database:

https://bugs.java.com/bugdatabase/view_bug?bug_id=4098033

Essentially, this is a design flaw in earlier versions of Java that they are not intending to fix in the Cloneable interface as to do so would break compatibility with some existing code.

Canoodle

@EpicPandaForce Probably because we don't want to mimic C++ in certain situations. Cloning should be used with care, most of the time it doesn't achieve what you want it to achieve. The missing thing in Java is to have const parameters, but copying every (mutable) object instance isn't a good solution. And yes, there are some things in which Java sucks, and this is one of them. Use Kotlin / data classes. – Cubby

Answer 3

In Java, there is this concept of marker interfaces. The Cloneable interface has no methods or fields and serves only to identify the semantics of being cloneable.

from the dev-x website:

Often you will come across interfaces in Java that have no behavior. In other words, they are just empty interface definitions. These are known as marker interfaces. Some examples of marker interfaces in the Java API include:

• java.lang.Cloneable
• java.io.Serializable
• java.util.EventListener

Soluk

I don't think it's a weird concept. Sometimes it's useful to be able to see if something can act as an alternate type. As others have said, Cloneable is broken though. – Tegan

They're supposed to act as mixins. Not my favourite mechanism in a strongly typed language such as java but it makes sense for Serializable, sorta. – Vaporizer

@Serializable would have made more sense. Or at least it would have done if annotations came a decade earlier. – Christophe

I like the last comment by tom :) There were quite a few features that should have been in a decade ago... – Champaign

Answer 4

On the project I work on, we've created an interface called PublicCloneable, it contains the clone method and specifies that it is public.

I find this one useful: the fact that there's a clone method, but you cannot access it doesn't help very much.

public interface PublicCloneable extends Cloneable {
    public Object clone();
}

Quasijudicial

What would be the way to use this interface (PublicConeable)? – Hartwell

@Otto: for example, a CloneHelper with a method public static PublicCloneable copy(PublicCloneable obj), which checks for null, or just copy(Object obj), and checks both null and instanceof PublicCloneable – Quasijudicial

When you return an object from a local cache for example... That said, serializing/deserializing is probably safer. – Quasijudicial

"and specifies that it is public." - Actually, the methods defined in an Interface are public by default. No need to mention this in code. @NicolasC – Twomey

Answer 5

Because the clone method is implemented in the Object class due to its "special" condition: the memory copy of objects of any kind.

Urbanism