Topic
No replies
WWFW_David_Polock
WWFW_David_Polock
1 Post
ACCEPTED ANSWER

Pinned topic Hashmap interoperability between IBM SDK 6 and IBM SDK 7

‏2013-09-10T15:06:19Z |

I just found a strange behaviour concerning hashmaps which are serialized/deserialized between different IBM SDK versions. It seems, that the SDK 6 (SR5) assumes that the internal bucketlist of the hasmap has at least 2 elements. While the public interface of the hashmap ensures, that the constraint is correct, the serialization to a client with IBM SDK 7, and the transport back to the IBM SDK 6 violates the internal constraint. As a result the internal rehash() operation fails to sort the elements at the correct indices - the hashmap gets corrupted.

The testcase:

with a IBM JDK 6 execute the following code:

HashMap h = new HashMap();
ObjectOutputStream os = new ObjectOutputStream( new FileOutputStream( "serverCreate.obj" ) );
os.writeObject( h );
os.close();
 

as a result, an empty HashMap is stored in the file serverCreateObj.

Now with a IBM JDK 7 execute the following code:

ObjectInputStream is = new ObjectInputStream( new FileInputStream( "serverCreate.obj" ));
HashMap h2 = (HashMap)is.readObject();
h2.put( "KVN", "101010" );
System.out.println( "Size of HashMap: " + h2.size() );
ObjectOutputStream os = new ObjectOutputStream( new FileOutputStream( "clientCreate.obj" ) );
os.writeObject( h2 );
os.close();

No magic here - we just insert a "string to string" mapping in the deserialized empty hashmap and serialize the hashmap back to the filesystem.

The size of the hashmap is the expected "1".

Now lets go back to IBM SDK 6. We read the hashmap from the filesystem an insert another value:

ObjectInputStream is = new ObjectInputStream( new FileInputStream( "clientCreate.obj" ));
HashMap h2 = (HashMap)is.readObject();
h2.put( "NNA", "VALUE" );
h2.put( "KVN", "101010" );
System.out.println( "Size of HashMap: " + h2.size() );

The hashmap with the initial mapping KVN=>101010 is read from the filesystem and the pairs NNA=>VALUE and KVN=>101010 (note, this is the same entry like the existing entry) are added to the hashmap.

Expected behaviour: Hashmap size is 2 and the contained elements are KVN=>101010, NNA=>VALUE.

Observed behaviour: Hashmap size is 3 and the contained elements are KVN=>101010, NNA=>VALUE, KVN=>101010!

The hashmap contains a duplicate key :-(

In the serialized (client) hashmap, the length of the bucket is transported with the value 1. One bucket with one element. The IBM JDK6 deserializes this and creates a new, empty bucketlist with the given size 1. Then, the key and value are read from the serialized file and inserted in the hashmap. The bucket size after deserialization is 1 and the hashmap functions correctly.

While inserting NAD=>VALUE in this hashmap, the system calls "rehash", which apparently does not work correctly for a bucketsize of 1.

I'am pretty sure, that this is a bug in the intenal hashmap data strucutures. Any comments?

 

  David