4

If a class is not Cloneable no object of this class can be cloned. Then why is clone() kept in the Object class and not in Cloneable interface?

NullUserException
  • 83,810
  • 28
  • 209
  • 234
Vidyakar Sharma
  • 67
  • 1
  • This might be way off, but it might be for some form of polymorphism, e.g. foreach `Object` in a collection, try cloning it, if it succeeded do one thing, if it threw an exception do another thing. – Eran Zimmerman Gonen Sep 14 '11 at 06:39
  • possible duplicate of [Java: Rationale of the Cloneable interface](http://stackoverflow.com/questions/709380/java-rationale-of-the-cloneable-interface) – Joachim Sauer Sep 14 '11 at 06:41
  • reading the answers [here](http://stackoverflow.com/questions/1138769/why-is-the-clone-method-protected-in-java-lang-object) or [here](http://stackoverflow.com/questions/709380/java-rationale-of-the-cloneable-interface) should help you. – e-MEE Sep 14 '11 at 06:44
  • @Joachin and e-MEE Those answers don't help one bit. They say `Cloneable` is "broken," but provide no explanation to the question the OP is asking (ie: "Why is the clone() method kept in Object?") – NullUserException Sep 14 '11 at 06:52
  • @NullUserException, [this particular answer helps](http://stackoverflow.com/questions/709380/java-rationale-of-the-cloneable-interface/709404#709404) in every single bit. Removing `clone` from `Object` after it was first introduced would have broken backward compatibility going by the Sun bug database entry. The answer falls in that area of Java's history where a decision was taken and could not be changed for the sake of our children. – Vineet Reynolds Sep 14 '11 at 07:03

2 Answers2

3

It was a design error in Java (yes, Java is not perfect!).

It's better to avoid cloning in Java. For example Josh Bloch points out in Effective Java, Item 11:

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, without 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. Despite this flaw and others, the facility is in wide use so it pays to understand it.

If you want your objects to be cloneable, implement a copy constructor or copy method.

Oleg Pavliv
  • 20,462
  • 7
  • 59
  • 75
0

  1. Cloneable is a marker interface, acts like an attribute to the user/developer to see if the class is clonebale.

  2. clone() is kept in Object class because in your clone() implementation it is advised that you call super's clone(), this can happen only if the super class has a clone function even if its not marked cloneable(by implementing Cloneable) hence keeping the clone() function in Object makes sense.

  3. clone() creates a different instance of the class altogether which like constructor should call super's method to create a full fledged instance.

Satyavrat
  • 139
  • 1
  • 10
  • Point 2 is wrong: a class can *always* call `super.clone()` because `Object` has `clone()`. Point 3 is not relevant here, I don't see how it's a reason to keep `clone()` in `object`. – Joachim Sauer Sep 14 '11 at 06:47
  • point 2 says, clone is kept in Object so that it can be called by any of its subclass(by calling super.clone()) even if it is not marked cloneable. point 3's relevance is that when we call super's constructor for creating an instance likewise we have to do it for clone also. not mandatory but strongly advised. – Satyavrat Sep 14 '11 at 06:52