This piece of code should put 3 key-value pairs in the hashtable and also should serialize the thus formed hashtable. Now when i am trying to retrive them back in another program by this piece of code:

The other program you mentioned: is it using same Java version and exact same code?
–
sfusseneggerNov 4 '09 at 7:26

Hi .. Yes the other program just tries to deserialize what ever was serialized by the first program. When i look into the object serialization program there are 3 objects, but when i look into the deserialization program it contains only 2 objects though the count says to be 3 ..
–
user202385Nov 4 '09 at 7:44

Any specific places i need to look into ..??
–
user202385Nov 4 '09 at 7:45

Could you please give us the code for SecondaryStructures which seems to be the key for the Hashtable ? Are those objects immutable once used as a key in the table ?
–
pgrasNov 4 '09 at 9:42

I too thought so and started debugging .. Did not find a solution but an interesting observation .. One of the keys is getting replaced while adding the key, so if the initial hashtable has 10 values to be filled and the first addition was at 6 and the next addition was at 4 the last addition was being added again at 4 .. I dont know how is that happening. The keys are different for sure. I tried it using hashmap instead of hashtable and it works perfectly fine .. Thnaks for replying .. If someone faces the same issue, i would like to know if they have same debugging symptoms ..
–
user202385Nov 4 '09 at 8:52

It is normal that several different keys get stored at the same position, the position is determined by a hash function. When several keys are stored at the same position, the entries (key+value) are chained. To get a value given a key, the key is hashed to find what position to look at and then the key is compared (with equals) with the key at the given position. So hashcode and equals have to be consistent and also stable over time...
–
pgrasNov 4 '09 at 12:15

HashMap uses "open hashing". That means, if you insert two different items whose hashCode methods generate the same unique number (this sometimes occurs) then the hash table solves this collision by simply inserting both entries into the same place as a linked list. Take a look into one entry within the hash table in debug mode: There's also an attribute with the name "next". This is a pointer to one further entry which is located at the same position within the hash table. In other words: The HashMap implementation manages "linked lists" at every position in the table. If one or more entries get stored at the same location (if their hashCode method calculates the same value) then the concerning hash table position stores all these entries in a linked list.

The problem with serialization of hash tables is that the hash table stores the items internally at different locations. The concerning items do have different table positions before the serialization. After the deserialization you cannot find these items again because they are stored at differnt positions, now. I don't know whether this was the intention of Sun/Oracle. Is it a bug? I've got the same problem. I'm looking for any solution.

I located my fault: Serialization of HashMaps/Hashtables and the extraction of equivalent entries from the deserialized version of the map works well. But the key objects in my map overwrote the hashCode method. And this implementation was wrong. Take a look at: link. If you are faced with the problem that you cannot get identical key objects from a deserialized hash map then you should check your hashCode implementation of the key object.
–
Andreas 'PAX' LückApr 2 '11 at 19:35

Its a very important point in serialization topic. Hashtables storekey/value pairs in buckets, which is where an entry resides. The bucket location itself is made from the hashCode() of the key. So, now, if the key is an object whose hashCode() function is not overridden (ie; its using Object.hashCode()), then the generation of this hashcode value can be different from JVM to JVM or even from one program run to another. Almost certainly, when its deserialized, its not the same object, but rather a new reference of that instance, which can result in a different hashCode() then at the time it was being serialized, thus resulting in either stream corruption OR simply object not found. You can do either this or provide a primitive datatype for the key. So, an Integer can be a key and you can use Hashtable.put(2, myValueObj); → since java autoboxes integer primitives.