enum et hashcode non stable ?

Bonjour,

Je rencontre un problème avec les enum et le calcul du hashcode et je ne trouve pas d'autres informations que ce vieux ticket trouvé sur le site de sun : http://bugs.sun.com/bugdatabase/view...bug_id=6421053

Mon problème : le calcul du hashcode d'un enum n'est pas constant. J'ai testé sur plusieurs JVM dont une 1.6.0_01-b06.

Je voulais savoir s'il y avait eu des avancés sur ce sujet et connaitre les bonnes pratiques par rapport aux enums (utilisation en tant que clé dans une hashmap, utilisation d'une enumMap ??)

Merci,

Pop_up

EnumMap utilise la valeur ordinale de l'instance énumérée. Donc pas de pb....
meme aprés serialisation et reconstitution dans un nouveau monde ton enumMap sera correct.

Salut,


Et quel est le problème avec cela ?
Le calcul du hashCode n'a pas à être constant entre différente exécution. Il suffit qu'il soit constant pendant toute l'exécution d'une même application...

a++

+1 ca ne pose aucun problème.

En fait, j'ai rencontré un problème avec un objet qui a des enum en tant qu'attributs. Cet objet est utilisé comme clé dans une hashMap.
Entre deux JVM, la méthode get de la map me retourne null (pas même hashcode) de façon aléatoire.

D'où ma question sur les bonnes pratiques à ce niveau :aie:

EDIT : peut-être utiliser un toString sur mes enum dans le calcul du hashcode de mon objet ?

Merci,

Pop_up

tu peux donner un exemple concret de code qui foire? Par ce que "entre deux jvm"? La Map est limitée à une seule JVM que je sache :D

Je suis dans un environnement complétement distribué.

Mon object qui me sert de clé :

class A {
MonEnum enum = MonEnum.ENUM;
}

Sur mon host 1, cet objet est mis dans une HashMap :
maMap.put(A, toto);
Ma map est sérialisée sur mon host 2.
Ma clé est reconstruite sur cet host 2. Ma tentative de maMap.get(A) me retourne null.

Nous avons donc un hashcode calculé sur host 1 lors du put et un hashcode calculé sur host 2 lors du get.

D'où mes interrogations sur la manipulation des enums lors du calcul du hash.

Pop_up

Salut,


D'après ton code le problème viendrait plutôt du hashCode de la classe A et non pas de l'enum.

Pour une même valeur de l'enum, le hashCode d'enum sera peut-être différent entre les deux JVM, mais il restera identique sur la même JVM, et donc ne posera pas de problème lorsqu'il est utilisé en tant que clef...

:arrow: On pourrait voir la méthode hashCode() de la classe A ??? De même que la méthode equals() !

a++

Ok,

Ca donnerais un truc dans le genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

class A { MonEnum enum = MonEnum.ENUM;   @Override public int hashCode() { final int prime = 31; int result = 1; result = prime * result +enum == null) ? 0 : enum.hashCode()); return result; }   @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (getClass() != obj.getClass()) return false; final A other = (A) obj; if (enum == null) { if (other.enum != null) return false; } else if (!enum.equals(other.enum)) return false; return true; } }

---

En fait, le enum.hashCode() fait un appel à Object.hashcode() qui renvoie l'adresse mémoire. Après sérialisation, je pourrais rencontrer un problème, non ?
Peut-être qu'effectivement la HashMap va reconstruire l'ensemble de ses index après sérialisation...? Mais si tel est le cas, mon bug vient d'ailleurs.

C'est vraiment le code que tu utilises ? :arrow: il ne compile pas (mot clef enum utilisé comme nom de variable).

Pour moi ce code (une fois corrigé) ne devrait pas posé de problème. Maintenant si tu veux une réponse exact il faut poster le code exact...

a++

Pour moi,le problème ce n'est pas le code ;)
Ce n'était qu'un exemple. De plus, je me sers de la génération automatique des hashcode/equals d'eclipse.

Maintenant, je me pose la question sur la reconstruction des index après la serialisation d'une hashMap. Je vais regarder ça.

EDIT : merci pour la balise code

Mais quel est le problème précis alors ? Le fait que le hashCode ne soit pas identique d'une JVM à l'autre ne devrait pas poser de problème...

a++

je viens de regarder hashmap. Effectivement, elle implémente Serializable et non pas Externalizable, il ne fait donc aucun traitement particulier sur ses liste internes. Donc, indépendement des enums, si le hashcode de la clé change pendant la désérialisation (ce qui est normal avec identityhashcode), il va y avoir un clash entre les hashcode des enum, et la valeur de hashcode sous laquelles ils sont entrés. Exemple la map d'origine a cette structure:

Code:

---

1 2 3 4 5 6 7

Map [hash 1...10] -> [Object hashcode=3, value="A"] [hash 11...20] [hash 21...30] [hash 31...40] [hash 41...50]

---

et la Map d'arrivvée à cette structure:

Code:

---

1 2 3 4 5 6 7

Map [hash 1...10] -> [Object hashcode=26, value="A"] [hash 11...20] [hash 21...30] [hash 31...40] [hash 41...50]

---

Mais ceci viens du fait que ton hashcode n'est pas cohérent avec equals dans le cas de ta Map. Certe il reste coherent dans la jvm mais pas d'une jvm à l'autre, hors si tu veux des clés de HashMap qui fonctionnent en sérialisation, le hashcode doit être coherent d'une execution à l'autre.

Deux possibilité pour toi.

1) dans ta classe A qui enveloppe l'enum, tu ne prend pas la hashcode de ton enum (mais plutot son index ou sa valeur)
ou
2) si tu veux utiliser les enum comme clé, utiliser EnumMap, qui est dédiée à utiliser des enum comme clé (et est plus rapide que la hashmap)