Question

I have a quick question regarding the clone() method in Java, used as super.clone() in regard to inheritance – where I call the clone() method in the parent class all the way up from the button.

The clone() method is supposed to return a copy of this object, however if I have three classes in an inheritance heirachy and call super.clone() three times, why doesn’t the highest class in the inheritance heirachy, just under class Object, get a copy of that class returned?

Suppose we have three classes: A, B and C, where A -> B -> C (inherit = ->)

Then calling super.clone() in class C, invokes clone() in B which calls super.clone(), invoke clone() in A which call super.clone() ‘this time Object.clone() gets called’. Why is it not a copy of the this object with respect to class A that gets returned from Object.clone()? That sounds logical to me.

Answer 1

It sounds like there are at least two problems at work here:

1. It sounds like you’re confused about how clone() normally gets implemented.

2. It sounds like you’re thinking that cloning is a good idea (vs. using a copy constructor, factories or their equivalent).

Here is an example of an implementation of a clone method:

@Override 
public Object clone() throws CloneNotSupportedException {   
    //get initial bit-by-bit copy, which handles all immutable fields
    Fruit result = (Fruit)super.clone();

    //mutable fields need to be made independent of this object, for reasons
    //similar to those for defensive copies - to prevent unwanted access to
    //this object's internal state
    result.fBestBeforeDate = new Date( this.fBestBeforeDate.getTime() );

    return result;
}

Note that the result of super.clone() is immediately cast to a Fruit. That allows the inheriting method to then modify the Fruit-specific member data (fBestBeforeDate in this case).

Thus, the call to a child clone() method, while it will call the parents’ clones, also adds its own specific modifications to the newly made copy. What comes out, in this case, will be a Fruit, not an Object.

Now, more importantly, cloning is a bad idea. Copy constructors and factories provide much more intuitive and easily maintained alternatives. Try reading the header on the Java Practices link that I attached to the example: that summarizes some of the problems. Josh Bloch also has a much longer discussion: cloning should definitely be avoided. Here is an excellent summary paragraph on why he thinks cloning is a problem:

Object’s clone method is very tricky. It’s based on field copies, and
it’s “extra-linguistic.” It creates an object without calling a
constructor. There are no guarantees that it preserves the invariants
established by the constructors. There have been lots of bugs over the
years, both in and outside Sun, stemming from the fact that if you
just call super.clone repeatedly up the chain until you have cloned an
object, you have a shallow copy of the object. The clone generally
shares state with the object being cloned. If that state is mutable,
you don’t have two independent objects. If you modify one, the other
changes as well. And all of a sudden, you get random behavior.