Cloning v/s Reference Copying

[Naseem Khan]

Hi Sir...

I hav a doubt regarding cloning v/s reference copying.
If u clone any object by java's clone method. It gives u copy of original object.
Say i hav simple code.

Clone Test c1=new CloneTest();
CloneTest c2=(Object)c1.clone(); // gets the clone of newly created object.

System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object. Same behaviour u can get by jst reference copying like this.

CloneTest c1=new CloneTest(), c2;
c2=c1; //c1 and c2 prints same address after this line

so wat the difference between the two and wat is the power of cloning? I know its shallow copying.

plz help me!!!

Thanks and Regards

Naseem khan

[Joanne Neal]

Originally posted by Naseem Khan:

Clone Test c1=new CloneTest();
CloneTest c2=(Object)c1.clone(); // gets the clone of newly created object.

System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object.

If that is the case then you have implemented your clone() method incorrectly. Post the code for CloneTest.clone().

[Rick O'Shay]

Good observation. It appears clone() is useless and in fact that is the case.

Here's the problem. If you implement the cloneable interface you have to copy variables from the original to the new object inside your clone method. Don't bother, however, because it will only work if your parent class does the same. If you can't do something reliably and consistently it's not much use.

Now, let's say you decide to use it anyway. The stipulation is that you call super.clone() on your parent. The clone() method is protected in Java, so it appears to be a problematic stipulation. Not so, the JVM breaks the contract and let's anybody call the protected clone() method as if it were public. It gives you an indication of what a badly thought out hack clone really is.

IMO it's better to provide a copy constructor and a copy method to implement a logical copy rather than pretending you can do deep copies of objects with the clone interface when you can't:

class Rocket
{
public int a;
private int b;
protected int c;

Rocket( Rocket source ) {
this.a = source.a;
this.b = source.b;
this.c = source.c;
}

Rocket copy( Rocket source ) { return new Rocket( source ); }

}

[Mr. C Lamont Gilbert]

Originally posted by Rick O'Shay:
Good observation. It appears clone() is useless and in fact that is the case.

Wrong my friend. First to the OP, you must have botched your clone method as already posted here. Now to address Mr. O'Shay.

Originally posted by Rick O'Shay:
Here's the problem. If you implement the cloneable interface you have to copy variables from the original to the new object inside your clone method. Don't bother, however, because it will only work if your parent class does the same. If you can't do something reliably and consistently it's not much use.

The original members of the cloned class are automatically referenced by the newly created one when you call clone. So you don't have to do this copying you say. If your parent class does not provide 'cloneability' then as a decendent, you can not clone. C'est la vie.

Originally posted by Rick O'Shay:

Now, let's say you decide to use it anyway. The stipulation is that you call super.clone() on your parent. The clone() method is protected in Java, so it appears to be a problematic stipulation. Not so, the JVM breaks the contract and let's anybody call the protected clone() method as if it were public. It gives you an indication of what a badly thought out hack clone really is.

I don't know what you are trying to say here, but what you actually did say is not true.

Originally posted by Rick O'Shay:

IMO it's better to provide a copy constructor and a copy method to implement a logical copy rather than pretending you can do deep copies of objects with the clone interface when you can't:

class Rocket
{
public int a;
private int b;
protected int c;

Rocket( Rocket source ) {
this.a = source.a;
this.b = source.b;
this.c = source.c;
}

Rocket copy( Rocket source ) { return new Rocket( source ); }

}

But of course this fails

  
class Fueelage extends Rocket {
   public int x;
   protected int y;
   private int z;
}
 
Rocket r = new Fueelage();
Rocket copy = r.copy(r);
//which ignores the variables x,y,z and creates an improper copy

I think you are on the right track though. You need to mix the two approaches like so;

class Rocket implements Cloneable
{
   public int a;
   private int b;
   protected int c;
 
   Rocket( Rocket source ) {
      this.a = source.a;
      this.b = source.b;
      this.c = source.c; 
   }
   
   public Rocket copy() 
   { 
       try {
            Rocket r = (Rocket)super.clone();
            //correct object references as needed
            return r;
       }
       catch(CloneNotSupportedException e){
            assert false : "WTF?";
            return null;
       }
   }
}
class Fueelage extends Rocket {
   public int x;
   protected int y;
   private int z;
   public Rocket copy(){
       Rocket r = super.copy();
       r.x = 0;
       r.y = 4; //or whatever you need to do
       return r;
   }
}

Voila

[Stefan Wagner]

Originally posted by Naseem Khan:


System.out.println("Original object " + c1 + " Cloned object " + c2);

here c1 and c2 both display same address. It means c1 and c2 are pointing to same object.

Perhaps the whole confusion is belonging to the word 'address' here.
How do you print addresses, Sir?
[ August 27, 2005: Message edited by: Stefan Wagner ]

[Ronnie Ho]

Good observation Stefan, i think Naseem may have mis-understood the hashcode as the memory address of the object referenced.

[Mr. C Lamont Gilbert]

Originally posted by Ronnie Ho:
Good observation Stefan, i think Naseem may have mis-understood the hashcode as the memory address of the object referenced.

He probably did, but that misunderstanding did not lead him to any false conclusions!?