commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julien Buret (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (COLLECTIONS-266) Issue with MultiKey when serialized/deserialized via RMI
Date Fri, 14 Sep 2007 08:18:32 GMT

    [ 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:17 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);
    }

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.
   

      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).

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.

  
> 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.


Mime
View raw message