Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <15386711.1189760012590.JavaMail.jira@brutus>
Date: Fri, 14 Sep 2007 01:53:32 -0700 (PDT)
From: "Joerg Schaible (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (COLLECTIONS-266) Issue with MultiKey when
 serialized/deserialized via RMI
In-Reply-To: <20828754.1189544672037.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COLLECTIONS-266?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527413 ]=
=20

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

Well, this problem with Enums has a history:

- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6421053
- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=3D6373406

However, in the end you're right and the hashCode should not have been stor=
ed in the MultiKey in this way. We might solve this by adding a readResolve=
 method:

  private Object readResolve() {
      return new MultiKey(keys, false);
  }

that way we create a new MultiKey with the correct hashCode. Your solution =
with the transient member will break the serialization compatibility, since=
 you changed the binary layout. Therefore the hashCode member *must* be ser=
ialized - otherwise you have to change also the serialVersionUID. But with =
a private calculateHashCode method and setting the hashCode member not to f=
inal, we can implement readResolve different:

  private Object readResolve() {
      calculateHashCode();
      return this;
  }

But our clirr report may still choke about the final.

- J=C3=B6rg

> Issue with MultiKey when serialized/deserialized via RMI
> --------------------------------------------------------
>
>                 Key: COLLECTIONS-266
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-26=
6
>             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, TestCollection=
s266.java, TestCollections266.java, TestCollections266.java
>
>
> This is because the hash code of MultiKey is calculated only once.=20
> So if the MultiKey is deserialized in an other jvm, and if one at least o=
f the subkeys defines its hash code with System.identityHashCode() (for exa=
mple all the enums does), then the hash code of the MultiKey is no longer v=
alid, and you can't retreive the key in your Map.
> I fixed it by making the cached hash code field transient, and by recalcu=
lating the hash code during deserialization.=20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.