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

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


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.

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Buret updated COLLECTIONS-266:
-------------------------------------

    Attachment: MultiKey.java

Here is the updated source file.
Hope this help.

> 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
>         Attachments: MultiKey.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.

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated COLLECTIONS-266:
--------------------------------------

    Attachment: COLLECTIONS-266.patch

Julien's fix as a patch.

> 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
>         Attachments: COLLECTIONS-266.patch, MultiKey.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.

    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526862 ]

Henri Yandell commented on COLLECTIONS-266:
-------------------------------------------

The patch seems good to me. Need to make a unit test and then apply.

> 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
>         Attachments: COLLECTIONS-266.patch, MultiKey.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.

    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526945 ]

Henri Yandell commented on COLLECTIONS-266:
-------------------------------------------

While creating the test I realized that the use case that found this problem seems quite rare.

* MultiKey goes into Map.
* Map gets sent through serialize/deserialize.
* We have a new map, with a new multikey inside, with a new object inside that, and the multikey has based its hashCode on the old address of the object and not the new one.

If you dig that object out of the map, and then use it to try and get itself back out of the map; then you've got a problem. So definitely a bug of sorts.

But how did you get access to the object in the first place? :)

In my unit test, I transfer the Map, then have to get the key back out of the map to then use in a get request. ie:

        MultiKey mk2 = (MultiKey) map2.keySet().iterator().next();
        assertEquals(TWO, map2.get(mk2));

I find that the test passes for both the old code and your new code. Any idea what I'm doing differently?

> 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
>         Attachments: COLLECTIONS-266.patch, MultiKey.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.

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated COLLECTIONS-266:
--------------------------------------

    Attachment: TestCollections266.java

Attaching the unit test.

> 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
>         Attachments: COLLECTIONS-266.patch, MultiKey.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.

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julien Buret updated COLLECTIONS-266:
-------------------------------------

    Attachment: TestCollections266.java

I have updated the test and now it fails before the patch and is successful after.

In the test, the hash code of KEY_266 depends of the current (simulated) JVM (like System.identityHashCode() ).  

HTH

> 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
>         Attachments: COLLECTIONS-266.patch, MultiKey.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.

    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527307 ]

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

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated COLLECTIONS-266:
--------------------------------------

    Fix Version/s: 3.3

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

     [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Yandell updated COLLECTIONS-266:
--------------------------------------

    Attachment: TestCollections266.java

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

    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527365 ]

Joerg Schaible commented on COLLECTIONS-266:
--------------------------------------------

IMHO the key simply violates the contract. Extract from Javadoc to Object.hashCode:

- If two objects are equal according to the equals(Object)  method, then calling the hashCode method on each of the two objects must produce the same integer result

It also states:

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

Without testing it, but if you use this key not as part of a MultiKey, but of a HashMap directly, you might get the same results.

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

    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527381 ]

Julien Buret commented on COLLECTIONS-266:
------------------------------------------

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.

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

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

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

 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.

Sorry for the multiple edits, but what I would like is to underline this sentence of the hashCode contract :  "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);
    }

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

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