Java Cloneable interface – Is it broken?

In a Java application, even if a class implements Cloneable interface, we can not make a clone of the class. This itself says a lot about broken behavior of cloning in Java. In this post, I will explore other reasons for saying so.

In cloning in Java, we discussed the various ways of creating clone of Java objects including shallow and deep cloning, copy constructors and some best practices. Now let’s discuss about Cloneable interace gaps.

Table of contents

How Cloneable interface is braken?
What expert says
Java copy best practices

How Java Cloneable interface is braken?

  1. The very first gap is that clone() method should have been in Cloneable interface. If you implement Cloneable interface(don’t override clone() method) then it does not affect a single thing in your class on runtime. In fact, the default behavior should have been if Class A implements Cloneable then someone should be able to do this:
    //Ideal behavior; Cloneable should have been implemented like this
    
    class A implements Cloneable
    {
    	//member attributes and methods
    }
    
    class B
    {
    	A a = new A();
    	if(a instanceof Cloneable)
    	{
    		A copied = a.clone(); //I should be able to do this; But I am not.
    	}
    }
    
  2. clone() method does not call any constructor for creating the new instance, which makes it another variant of constructor with behavior not in our control. In other words: “Cloning invokes an extralinguistic way of constructing objects – i.e. without constructors“.
  3. Apart from above facts, it is also a classic example of spelling mistakes. The correct spelling should have been “Clonable“.
  4. There is no mechanism in java to create deep copies. Even calling super.clone() till the Object class, creates shallow copy.

What experts say about Java Cloneable interface


  1. Josh Block in an interview

    “There are a few design flaws, the biggest of which is that the Cloneable interface does not have a clone method. And that means it simply doesn’t work: making something Cloneable doesn’t say anything about what you can do with it. Instead, it says something about what it can do internally. It says that if by calling super.clone repeatedly it ends up calling Object’s clone method, this method will return a field copy of the original.”


  2. Ken Arnold in an inteview

    “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.”

Java copy best practices

As discussed in my previous post, use factory methods when you need to have a copy of an object. It has following benefits:

  1. You can return an instance of different class also if needed. For example, If someone wants to copy a LinkedList, if needed you can return an ArrayList also.
  2. You can choose whether you need to make deep or shallow copy.
  3. You can decide which members needs to be copied and which not.
  4. Different methods can have different names clearly pointing their responsibilities.

I hope this post shed some light on broken behavior of Java Cloneable interface (marker interface) and best practices while creating copy of an Object in Java.

Happy Learning !!

Was this post helpful?

Join 7000+ Fellow Programmers

Subscribe to get new post notifications, industry updates, best practices, and much more. Directly into your inbox, for free.

12 thoughts on “Java Cloneable interface – Is it broken?”

  1. After the discussion with my colleagues, we come on final decision, why java does not keep clone method in cloneable interface. Ans :- We know method implementation is possible only in a Class, that’s why java has provided the implementation in a Object so that each and every class in Java can access the clone method and don’t have to provide cloning logic explicitly.

    Cloneable Interface :- is a marker which says to JVM, the class which implements it, should be treated as special class which would eligible for Clone.

    Why clone method is Protected in Object class :- For the security reason, if any developer by mistaken implements the cloneable interface, then even java does not allow to create the clone of the object outside the class hierarchy. If we want to access clone outside the class hierarchy we need to provide our own implementation to provide the clone outside.

  2. If I have a class (Sample.java) with only primitive members and the class implements the cloneable interface but DOES NOT override the clone method, then it should work right? so something like:
    Sample sample = new Sample();
    Sample copy = sample.clone(); // here copy will be an actual clone as we have only primitive values even though we do not override the clone method.

    Is this right?

      • thanks for the clarification I got a little confused because of your below statement:
        A a = new A();
        if(a instanceof Cloneable)
        {
        A copied = a.clone(); //I should be able to do this; But I am not.
        }
        //I should be able to do this; But I am not. (this actually means you can do it, it compiles and it works if the object only has primitive fields)

        • Case 1 : The method clone() from the type Object is not visible

          public class A implements Cloneable
          {
              //member attributes and methods
          }
           
          class B
          {
              public static void main(String[] args) throws CloneNotSupportedException
             {
                 A a = new A();
                 if(a instanceof Cloneable)
                 {
                     A copied = a.clone(); //The method clone() from the type Object is not visible
                 }
             }
          }
          

          Case 2: When you override clone() method, then only program will compile.

          public class A implements Cloneable
          {
              //member attributes and methods
             @Override
             protected A clone() throws CloneNotSupportedException
             {
                // TODO Auto-generated method stub
                return (A)super.clone();
             }
          }
           
          class B
          {
              public static void main(String[] args) throws CloneNotSupportedException
             {
                 A a = new A();
                 if(a instanceof Cloneable)
                 {
                     A copied = a.clone(); //Now I can do this.
                 }
             }
          }
          
  3. This is a year old, I can tell there aren’t many linguists on here.

    Clonable … Absolutely not!. Adding -able to a word that ends in e has one rule. You must never remove the e if it changes the pronunciation. Clonable would make the o short, while cloneable would keep the long o sound.

    Stick to Java since after reading you blog I see the shortcomings of Clone/Cloneable now.

  4. 4: A copy constructors name will have the same name as the class, else it is not a constructor, it is just a member function. Or am i missing something?

      • In Java when ever you create a class like:

        //Ideal behavior; Cloneable should have been implemented like this

        class A implements Cloneable
        {
        //member attributes and methods
        }

        class B
        {
        A a = new A();
        if(a instanceof Cloneable) // you can not do this as clone() is not there in the Cloneable interface
        {
        A copied = a.clone(); // this is possible because object class is the super class of every class, but don’t give optimize performance
        }
        }

  5. Your thought : The correct spelling should have been “Clonable“.

    My Thought:
    Neither Clonable nor Cloneable are English dictionary words, so it really doesn’t matter what the spelling is. Since the spelling itself doesn’t exist, it can’t be a mistake! 🙂

    Also, going by “Bounce : Bounceable”, “Clone: Cloneable” seems correct. So, this isn’t a “classic” example of spelling mistake.
    Also this particular reason is not at all any valid reason that the interface is broken. It shouldn’t have been even listed.
    —————————————————————

    Your thought : There is no mechanism in java to create deep copies.

    My thought : What do you think about Serialization? It creates deep copies. Agreed, however, that clone is only good for shallow copying.

    • Partha, OK Its not that much classic.. and there are other such mistakes.. I agree.

      But, serialization is not replacement of deep copies for sure.. Serialization involves a lot of design considerations i.e. non-serializable fields should be declared transient etc. Then it has serial version id concepts.

      A true deep copy mechanism will not enforce such restrictions on developers. So, I do not agree here…

      https://howtodoinjava.com/java/serialization/java-serialization/

Comments are closed.

HowToDoInJava

A blog about Java and its related technologies, the best practices, algorithms, interview questions, scripting languages, and Python.