Question about clone a Hashtable

[George Lin]

Hello everyone,


I want to clone the content of a Hashtable (its keys, its values and its key-value relationship). But I have found that the clone method can not completely clone a Hashtable, as is mentioned in the description of clone method of Java API Specification,

Creates a shallow copy of this hashtable. All the structure of the hashtable itself is copied, but the keys and values are not cloned. This is a relatively expensive operation.

I am wondering what is the efficient and effective approach of cloning a Hashtable, including the clone of its keys, its values and its key-value relationship.


Thanks in advance,
George

[Jeanne Boyarsky]

George,
You can loop through the set of keys in the HashTable. For each one, get the associated value. Then clone the key/value and put them in a new HashTable.

[Edwin Dalorzo]

Serialize the HashTable then deserialize it into a new Object. That's the only way I know with out having to iterate cloning every item.

[George Lin]

Thanks Edwin,

Originally posted by Edwin Dalorzo:
Serialize the HashTable then deserialize it into a new Object. That's the only way I know with out having to iterate cloning every item.

I am very interested in this method. I am wondering whether all the keys and values are needed to be serializable if I want to use your method. Are the relationship (reference) of the objects unaffected?

It is highly appreciated if you could provide some sample source codes about your method. :-)


regards,
George
[ May 15, 2005: Message edited by: George Lin ]

[George Lin]

Thanks Jeanne,

Originally posted by Jeanne Boyarsky:
George,
You can loop through the set of keys in the HashTable. For each one, get the associated value. Then clone the key/value and put them in a new HashTable.

I have written a simple sample below, but from the sample's output, I have found out that it seems that the clone method of Hashtable copies the the content of both keys and values, not as mentioned in the Java API specification of clone method of class Hashtable "but the keys and values are not cloned".

Do you know what points do the Java specification mean?

Hashtable table1 = new Hashtable();
table1.put ("key1", "value1");
Hashtable table2 = (Hashtable) table1.clone();
if (table2.containsKey ("key1"))
{
System.out.println ("Contains!");
table2.put ("key1", "value2");
String newValue1 = (String) table1.get ("key1");
System.out.println ("New value1 of table1: " + newValue1);
newValue1 = (String) table2.get ("key1");
System.out.println ("New value1 of table2: " + newValue1);
}
else
{
System.out.println ("Not contains!");
}

Output is:

Contains!
New value1 of table1: value1
New value1 of table2: value2


regards,
George

[Henry Wong]

I have written a simple sample below, but from the sample's output, I have found out that it seems that the clone method of Hashtable copies the the content of both keys and values, not as mentioned in the Java API specification of clone method of class Hashtable "but the keys and values are not cloned".

Do you know what points do the Java specification mean?

Why do conclude that the keys or values are copied when you clone the hashtable? When you call the put() methed on the cloned hashtable, it simply replaces the old reference with the new reference. You can't make the conclusion that the old reference was a copy of the original and not the same reference.

Henry

[Henry Wong]

Actually, this is a good example of why a shallow copy is fine for most cases of cloning a hashtable. The operations on the hashtable are just with references -- and will not change the object itself. The only time that you need a deep copy, is when you manipulate both the hashtable and the objects in the hashtable itself. For objects likes strings, it is fine because these objects can't be changed.

Henry

[George Lin]

Thanks Henry,

Originally posted by Henry Wong:
Actually, this is a good example of why a shallow copy is fine for most cases of cloning a hashtable. The operations on the hashtable are just with references -- and will not change the object itself. The only time that you need a deep copy, is when you manipulate both the hashtable and the objects in the hashtable itself. For objects likes strings, it is fine because these objects can't be changed.

Henry

Your reply is very helpful! Do you mean shallow copy of clone related concepts means copy only the reference?

Could you please show me some sample source codes dealing with why shallow copy is not enough and deep copy is needed?


regards,
George
[ May 16, 2005: Message edited by: George Lin ]

[Ragu Ram]

Do you mean shallow copy of clone related concepts means copy only the reference?

Yes

Could you please show me some sample source codes dealing with why shallow copy is not enough and deep copy is needed?

 
public static void main(String[] args) {
class MyClass {
String myStr;
public String toString() {
return ":::" + myStr;
}
}
Hashtable myTable = new Hashtable();
MyClass m = new MyClass();
m.myStr="Test1";
myTable.put("1",m);
Hashtable my2ndTable = (Hashtable)myTable.clone();
System.out.println(my2ndTable.get("1"));
m.myStr = "Test2";
System.out.println(my2ndTable.get("1"));
} 

Result is

:::Test1
:::Test2

This shallow copy applies to all Collections and arrays.
Note that you can clone an array also.

Going for shallow/deep copy is not a rule of thumb and your business scenario dictates which one you are to choose.

In the example given above deep copy is not possible as MyClass doesnt implement the Cloneable interface.

I am wondering whether all the keys and values are needed to be serializable if I want to use your method

You guessed it right all the key/value pairs need to be serializable. I am not sure if having them Externalizable helps.

[Edwin Dalorzo]

It is highly appreciated if you could provide some sample source codes about your method. :-)

Hi, George. Here it comes:

package edalorzo.scjp;
 
import java.io.*;
import java.util.*;
 
public class Exceptions{
 
public static void main(String args[])
{
List writeList = new ArrayList(5);
List readList = null;

writeList.add("Lord");
writeList.add("of");
writeList.add("code");

//Serialize
try{
ObjectOutputStream os = new ObjectOutputStream(new FileOutputStream("list.bin"));
os.writeObject(writeList);
os.close();
}catch(IOException e){}

//Deserialize
try{
ObjectInputStream os = new ObjectInputStream(new FileInputStream("list.bin"));
readList = (ArrayList) os.readObject();
}
catch(IOException e){}
catch(ClassNotFoundException e){}

System.out.println("\nDeserialized list\n");
Iterator iter = readList.iterator();
while(iter.hasNext()){
String item = (String) iter.next();
System.out.println(item+" ["+System.identityHashCode(item)+"]");
}

System.out.println("\nOriginal list\n");
iter = writeList.iterator();
while(iter.hasNext()){
String item = (String) iter.next();
System.out.println(item+" ["+System.identityHashCode(item)+"]");
}
}
}

Notice how hashcodes are different, meaning different object from the original to the deserialized. Object of the list have to be serializable, of course.

[George Lin]

Thanks Edwin,

Originally posted by Edwin Dalorzo:

package edalorzo.scjp;
 
import java.io.*;
import java.util.*;
 
public class Exceptions{
 
    ...
 
}

Notice how hashcodes are different, meaning different object from the original to the deserialized. Object of the list have to be serializable, of course.

Your reply and sample are very helpful! Your method is very novel!

I have an issue dealing with your sample. I think if the hash code values of two objects are different, then I think the two objects are different (not pointing to the same memory space). But I am not quite sure about this point. Am I correct? Do you have any online materials dealing with hash code computation, which can show that if two objects are different, then the hash values are different?


regards,
George

[George Lin]

Thanks Ragu,

Originally posted by Ragu Ram:

 
public static void main(String[] args) {
class MyClass {
String myStr;
public String toString() {
return ":::" + myStr;
}
}
Hashtable myTable = new Hashtable();
MyClass m = new MyClass();
m.myStr="Test1";
myTable.put("1",m);
Hashtable my2ndTable = (Hashtable)myTable.clone();
System.out.println(my2ndTable.get("1"));
m.myStr = "Test2";
System.out.println(my2ndTable.get("1"));
} 

Result is


You guessed it right all the key/value pairs need to be serializable. I am not sure if having them Externalizable helps.

Your reply is very helpful! In your sample, when you are talking about shallow copy is not enough, do you mean the content of the "cloned" table "my2ndTable" could be affected by the original object reference "m"?

In the example given above deep copy is not possible as MyClass doesnt implement the Cloneable interface.

I do not agree with this point. I think we can copy MyClass objects manually, by creating new objects and set the values for each of its member variable field, even though it is not an efficient and intelligent method. I am wondering why you mentioned the "Cloneable" interface at this point?

You guessed it right all the key/value pairs need to be serializable. I am not sure if having them Externalizable helps.

I am always using Interface "Serializable", and I am wondering what is the use of Interface "Externalizable".


regards,
George

[Edwin Dalorzo]

Originally posted by Mr. Linn

I have an issue dealing with your sample. I think if the hash code values of two objects are different, then I think the two objects are different (not pointing to the same memory space). But I am not quite sure about this point. Am I correct? Do you have any online materials dealing with hash code computation, which can show that if two objects are different, then the hash values are different?

Hi, George. First notice that I am using the System.identityHashCode() and not the hashCode method of the Objects stored in the list. That is because hashCode method of the objects stored in the list could have been overriden and idententityHashCode() guarantees it will return the same hashCode() as it would have been returned by the Object class if the hashCode method would have not been overriden (as it is in this case because the list contains String objects).

The contract for the Object.hashCode says (JSDK 1.4 Documentation on Object Class)

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

You can test two Object are equal also using the equality operators (==, !=)

that's to say

String a = new String("George");
String b = a;
System.out.println(a==b); //Should print true and identityHashCode are the same

While

String a = new String("George");
String b = new String("George");
System.out.println(a==b); //Should print false and identityHashCodes are different

[George Lin]

Thanks Edwin, your reply is very great!!

Originally posted by Edwin Dalorzo:
Hi, George. First notice that I am using the System.identityHashCode() and not the hashCode method of the Objects stored in the list. That is because hashCode method of the objects stored in the list could have been overriden and idententityHashCode() guarantees it will return the same hashCode() as it would have been returned by the Object class if the hashCode method would have not been overriden (as it is in this case because the list contains String objects).

I have got all of your points except this one, the overriden issue. Could you please provide some sample cource codes to illustrate why identityHashCode is more convenient than hashCode method (I always use hashCode before)? What are your points when describing hashCode method by using String objects?

String a = new String("George");
String b = new String("George");System.out.println(a==b); //Should print false and identityHashCodes are different

I have tested that the output is true, which is not the same as we imagined. Do you know what is the reason?


regards,
George

[ May 18, 2005: Message edited by: George Lin ]
[ May 18, 2005: Message edited by: George Lin ]

[Ragu Ram]

Originally posted by George Lin
do you mean the content of the "cloned" table "my2ndTable" could be affected by the original object reference "m"?

Yes. The example demonstrated it right?

Originally posted by George Lin
I do not agree with this point.I think we can copy MyClass objects manually, by creating new objects and set the values for each of its member variable field, even though it is not an efficient and intelligent method. I am wondering why you mentioned the "Cloneable" interface at this point?

I agree with you that it is possible to copy objects by getting and setting stuff in a new object.
This is not cloning. but copying. For cloning an object that object needs to implement the clone interface.

public static void main(String[] args) throws CloneNotSupportedException {
class MyClass implements Cloneable{
String myStr;
public String toString() {
return ":::" + myStr;
}
public Object clone() throws CloneNotSupportedException {
return super.clone();
}
}
Hashtable myTable = new Hashtable();
MyClass m = new MyClass();
m.myStr="Test1";
MyClass m1 = (MyClass) m.clone();
System.out.println(m);
System.out.println(m1);
}

Output is
:::Test1
:::Test1

I am wondering what is the use of Interface "Externalizable"

Externalizable is an alternative to Serializable and it provides some call back methods to write the contents to a stream.

I am not very strong on this Class. have a look at the api It will give you some light on this.

I have tested that the output is true, which is not the same as we imagined. Do you know what is the reason?

Check out the hashCode and equals contracts.
If object1.equals(object2) then object1.hashCode must be = object1.hashCode()

The reverse ned not be true.

[Edwin Dalorzo]

Hi, George.

Originally posted by George Lin

I have got all of your points except this one, the overriden issue. Could you please provide some sample cource codes to illustrate why identityHashCode is more convenient than hashCode method (I always use hashCode before)? What are your points when describing hashCode method by using String objects?

Goerge, I am not saying that identityHashCode is better than hashCode itself. What you have to understand is that some classes override hashCode. Why? Most of time because these classes have already overriden the equals method. If two classes are said to be equal they musth have the same hashCode value returned, the contrary is not necesarily true, that's to say: two objects with the same hashCode are not necesarily equal. Why so? Because to different classes could have overriden the hashCode method producing the same hashCode, but no representing equals objects.

This firs snippet shows two object of type Integer (which overrides hashCode to represent its integer value)

Integer aInt = new Integer(65);
Integer bInt = new Integer(65);
System.out.println(aInt.hashCode());
System.out.println(bInt.hashCode());

Now two object with same hashCOde but are not the same type, not even value

Integer aInt = new Integer(65);
Character aChar = new Character('A');
System.out.println(aInt.hashCode());
System.out.println(aChar.hashCode());

Now two objects that overrides hashCode, most probably it is because the object has an overriden equals method too. That means that two object my be equal and yet not being represting the same object in memory.

Integer aInt = new Integer(65);
Integer bInt = new Integer(65);
System.out.println(aInt==bInt); //false
System.out.println(aInt.equals(bInt)); //true

Now, the original equals method, the one that comes from object return true if two object represent the same memory reference, that is to say they are compared using the equality operator ==.

So, once you have overriden the equals method the only way you have to obatin the value of hashCode as it would have been originally returned by the Object.hashCode method is to call System.identityHashCode().

Different indentityHashCode would prove to objects are different, because that would prove that they are different memory references.

And finally, this code...

String one = new String("George");
String two = new String("George");
System.out.println(one==two);

...does produce false. I have tested it, and I see false in my output monitor.
[ May 19, 2005: Message edited by: Edwin Dalorzo ]

[George Lin]

Thanks Ragu,

Originally posted by Ragu Ram:
[QB]

public static void main(String[] args) throws CloneNotSupportedException {
class MyClass implements Cloneable{
String myStr;
public String toString() {
return ":::" + myStr;
}
public Object clone() throws CloneNotSupportedException {
return super.clone();
}
}
Hashtable myTable = new Hashtable();
MyClass m = new MyClass();
m.myStr="Test1";
MyClass m1 = (MyClass) m.clone();
System.out.println(m);
System.out.println(m1);
}

Your reply is very helpful! I think in your sample, when the statement "MyClass m1 = (MyClass) m.clone();" is invoked, then the String member variable "myStr" is copied (cloned). But I do not quite understand how this member variable is copied. You simply invoked "super.clone()", and how does this statement make "myStr" be copied?


regards,
George

[George Lin]

Thanks Edwin,

Originally posted by Edwin Dalorzo:
So, once you have overriden the equals method the only way you have to obatin the value of hashCode as it would have been originally returned by the Object.hashCode method is to call System.identityHashCode().

Different indentityHashCode would prove to objects are different, because that would prove that they are different memory references.

[ May 19, 2005: Message edited by: Edwin Dalorzo ][/QB]

Your answer is great!

I think your purpose of using System.identityHashCode() is to identify whether two objects are pointing to the same memory. Am I correct?

I am wondering why you do not use "==". From your reply, I think "==" is the same as comparing return values from "System.identityHashCode()". Could you please help?


regards,
George