[
https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527429
]
Julien Buret commented on COLLECTIONS-266:
------------------------------------------
If the final modifier is a problem, an other solution could be to add a
transient field "hashCode2" and no longer use the old field "hashCode " in the
class (just keep it for compatibility).
There is no mention of the final keyword in the serialization spec about
compatible or incompatible changes:
http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html#5172
> Issue with MultiKey when serialized/deserialized via RMI
> --------------------------------------------------------
>
> Key: COLLECTIONS-266
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-266
> 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, MultiKey.java,
> TestCollections266.java, TestCollections266.java, TestCollections266.java
>
>
> 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.
