2013/01/03

HashMap serialization issue

Today, we discovered an interesting behaviour in Oracle JDK 7 with my colleague. This also affects OpenJDK 7. There is a change in the implementation of the HashMap serialization. If you serialize and then deserialize a HashMap, two private fields are changed. The first is threshold and the second is table. While these changes do not seem to have any effect on the public behaviour of the class, it makes various testing a little bit harder.

For example, you developed a client/server application that exchanges some objects. These objects might hold some properties in a HashMap. To test the correctness of the communication channel, you send a serialized object from the client to the server. The server deserializes the object, changes an attribute and sends the serialized version back to the client. The client performs the same changes to its version of the object and serializes it too. Then the client compares the serialized byte arrays. With JDK 7 it finds them different and this is a problem in my opinion. Or do you find it a completely insane integration test scenario? I already found it in many projects so I suppose it is not that uncommon and bad.

A reproducer can be found at GitHub. I also logged an issue with Oracle. They are now about to review it. However, I suppose they are not going to fix the issue since it does not influence the public API. Who cares about testers...

2 comments:

  1. I ran into this problem too. Do you have a url for the issue you filed with Oracle?

    ReplyDelete
  2. Quick look at grepcode reveals that `table` is a transient field so it is perfectly ok for it to change but also should not affect serialized class bytes.

    My question is if the threshold field differs after deserialization or only after remote modification of the HashMap? In the former case it seems like a bug altough not big perhaps.

    ReplyDelete

. .