Why is clone method present in Object if I have to implement Cloneable interface to use it?

Hi everyone,
The clone() method declared in Object class raises CloneNotSupportedException, if the class does not implement Cloneable interface. Then, why is the method present in Object class? Is it just to give a default implementation for clone method? Since Cloneable is an interface, it cannot have default implementation. If Cloneable is declared as a class, then it should be extended. But , Java does not support multiple inheritance. Am I right?
Still I wonder , how the JVM make sure that the calling class implements a Cloneable interface when it is trying to clone method? Is this check implemented in the clone method definition?

Object's clone() method probably just checks it using: this instanceof Cloneable. The reason that the clone() method is defined in the Object class, is because some 'magic' is needed to actually make a clone. First of all, a new object has to be created without the use of a constructor. Secondly, the object has to be of the same type as the original object, even though the original may only know its exact type at runtime. The designers probably felt it was easiest to put all this magic in the Object class, since it is a bit special to begin with.

The real question one should ask is, why is there a clone() method at all? Classes that lend themselves to having their instances cloned should have a copy constructor. Copy constructors are much easier to implement correctly, and don't need any magic to work.

Kalpana Periasamy wrote:Then, why is the method present in Object class?

Probably so we can always just call super.clone() and it will work.

Also, note that clone() and Cloneable have been around since the very beginning, or nearly so. A lot of decisions were made in the early days of Java where the designers didn't have the complete picture yet and didn't know where Java's path would lead. or else they simply had to go with what was the most expedient at the time in order to meet a release date.

Whenever you see something that looks a little bit weird, check to see if it's been around for a long time, and be willing to consider it in the context of the Java landscape 15-18 years ago.