is clone() will really clone the interface variable inside an object

Question

I have a class with clonable interface implemented

public class BaseModelItem extends WiSeConBaseModel implements Cloneable{
private ValueChangeObserver observer=null;

//setting interface other values here

    @Override
    public WiSeConBaseModelItem clone() {
        return (WiSeConBaseModelItem) super.clone();
    }
}

And the interface looks

public interface ValueChangeObserver {
onChanged(Object obj);
}

My question is I have five variables other than interface variable while cloning all five variables is getting but not this interface variable.

Is there any issue of cloning of an interface object or any other issue?

Thanks in advance

Answer 1

My question is I have five variables other than interface variable while cloning all five variables is getting but not this interface variable.

That will depend entirely on whether WiSeConBaseModel or any of the superclasses between it and Object implement clone and, if they do, what those clone methods do.

If they don't , then Object#clone is used. The documentation says:

The method clone for class Object performs a specific cloning operation. First, if the class of this object does not implement the interface Cloneable, then a CloneNotSupportedException is thrown. Note that all arrays are considered to implement the interface Cloneable and that the return type of the clone method of an array type T[] is T[] where T is any reference or primitive type. Otherwise, this method creates a new instance of the class of this object and initializes all its fields with exactly the contents of the corresponding fields of this object, as if by assignment; the contents of the fields are not themselves cloned. Thus, this method performs a "shallow copy" of this object, not a "deep copy" operation.

(my emphasis)

So with Object#clone , that code will end up with the original and the clone both referencing the same object via observer .

Answer 2

Is there any issue of cloning of an interface object or any other issue?

Conceptually, it is not right.
You don't clone interfaces.
You clone only instances.
So it means that in your case you want also to clone the interface implementations.

My question is I have five variables other than interface variable while cloning all five variables is getting but not this interface variable.

These variables are very probably primitives and the default clone() behavior is "fine" as primitives copy means primitive assignments such as clone.myInt = original.myInt and this doesn't result to a shared myInt variable between the original and the cloned object.

But this one :

private ValueChangeObserver observer = null;

is not a primitive.

So as you clone a BaseModelItem instance, the observer field will reference exactly the same object in the original and the cloned object.

So you should specify how to clone that variable.
You should rather write something like :

private ValueChangeObserver observer = null;
...
@Override
public WiSeConBaseModelItem clone() {
    WiSeConBaseModelItem clonedItem = (WiSeConBaseModelItem) super.clone();
    cloneItem.observer = observer.clone();
    return clonedItem;
}

So it means you will have to override clone() in each implementation of ValueChangeObserver but you will also have to defined clone() in ValueChangeObserver as it doesn't declare it :

public interface ValueChangeObserver {
   onChanged(Object obj);
}

In fact, you should not even use clone() and Cloneable() .
All that should make you realize that overriding clone() is complicate, error prone (and it has also a important limitation for final fields contained by mutable class as you cannot reassigned a final field).

So just forget clone() and favor rather the use of a copy constructor :

public WiSeConBaseModelItem copy() {
     WiSeConBaseModelItem copy = new WiSeConBaseModelItem(primitiveOne, primitiveTwo, primitiveThree, observer.copy() ...);
     return copy;
}

You may also use reflection libraries to perform copies.
It avoids writing boiler plate code.
Note that the processing time may be a little more important. So it should be considered.