You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Julien Buret (JIRA)" <ji...@apache.org> on 2007/09/14 10:18:32 UTC

[jira] Issue Comment Edited: (COLLECTIONS-266) Issue with MultiKey when serialized/deserialized via RMI

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