commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <>
Subject [jira] Commented: (COLLECTIONS-266) Issue with MultiKey when serialized/deserialized via RMI
Date Thu, 13 Sep 2007 23:17:32 GMT


Henri Yandell commented on COLLECTIONS-266:

Thanks Julien.

Digging into it, I was a bit confused by the isJVM1 flag as it makes both the deserialized
object and the TEST_266 object have the same hashCode. Then I realized that's probably how
enums work, so fits your use case above.

I think this is a special case of a bigger and simpler unit test that uses the natural hashCode
of the object (ie: same as System.identityHashCode). The current patch fails for that unit
test. I'll attach the test for your thoughts.

> Issue with MultiKey when serialized/deserialized via RMI
> --------------------------------------------------------
>                 Key: COLLECTIONS-266
>                 URL:
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: KeyValue
>    Affects Versions: 3.2
>            Reporter: Julien Buret
>            Priority: Minor
>             Fix For: 3.3
>         Attachments: COLLECTIONS-266.patch,,,,
> This is because the hash code of MultiKey is calculated only once. 
> So if the MultiKey is deserialized in an other jvm, and if one at least of the subkeys
defines its hash code with System.identityHashCode() (for example all the enums does), then
the hash code of the MultiKey is no longer valid, and you can't retreive the key in your Map.
> I fixed it by making the cached hash code field transient, and by recalculating the hash
code during deserialization. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message