[
https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527381
]
jburet edited comment on COLLECTIONS-266 at 9/14/07 1:19 AM:
-------------------------------------------------------------------
For Joerg: Here is the code of equals() and hashCode() methods of class Enum in
the sun 1.5 jvm:
public final boolean equals(Object other) {
return this==other;
}
public final int hashCode() {
return System.identityHashCode(this);
}
(Revert edit) And the HashMap will work fine in this case, because in its
writeObject() and readObject() methods, the hashCode of each key is not
serialized/deserialized: only the key, the value and the size of the map are
serialized: It works, I have tested it.
Edit: I read this in the hashcode() method description contract in the java 6
javadoc:
* Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently return
the same integer, provided no information used in equals comparisons on the
object is modified. This integer need not remain consistent from one execution
of an application to another execution of the same application.
was (Author: jburet):
For Joerg: Here is the code of equals() and hashCode() methods of class
Enum in the sun 1.5 jvm:
public final boolean equals(Object other) {
return this==other;
}
public final int hashCode() {
return System.identityHashCode(this);
}
I think (and I hope ;) ) that the class Enum does not violate the hashCode
contract - but you can see that the same enum will not have the same hashCode
in two different jvms. The conclusion is : never serialize the hashCode (at
least for a modular class like MultiKey).
Edit: I read this in the hashcode() method description contract in the java 6
javadoc:
* Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently return
the same integer, provided no information used in equals comparisons on the
object is modified. This integer need not remain consistent from one execution
of an application to another execution of the same application.
> 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.
