Discussion :

[guiom]

Bonjour à tous,

J'ai voulu utiliser l'interface Comparable dans mon code afin d'identifier et de classer des objets dans un TreeSet.
Les premières lignes de mon implémentation de compareTo(Object o) sont:
if ( this == o) {
return 0;
} else ... <code donnant un entier>

Ma classe est dans un environnement multithread, a tourné pendant des semaines sans soucis. Puis un beau jour, le programme a remonté une erreur assez bizarre me laissant supposer que j'avais 2 fois la même instance dans mon TreeSet...

Après un traquage assez hardu (multithread, héritage, environnement Web, plein de classe) et ce bug qui apparaît/disparaît... je suis arrivé à la conclusion que c'était mon test this==o qui ne renvoyait pas true bien que this et o soit la même instance.
J'ai notamment utilisé hashcode() pour vérifier mes suppositions et cela a régler mon bug:
if ( this.hashCode() == o.hashCode()) {
return 0;
} else if ...

Ceci renvoie toujours true quand this et o sont la même instance alors que le == ne le faisait pas toujours.

Quelqu'un sait-il ce qui se cache derrière == ? est-ce equals ? un code natif inconnu ?
Est-il normal qu'il ne renvoie pas toujours true en multithread ?

Ai-je bien fait de le remplacer par hashcode() ?


Pour info, j'ai quelques blocs static susceptibles de modifier mes instances Comparable... cela peut influer sur equals() à ma connaissance.

[iohack]

L'opérateur '==' effectue une comparaison sur les adresses des objets alors que la méthode equals() sert à vérifier si deux objets on un contenu identique ( dans le contexte ).
Personnellement, je n'aurais pas utilisé la méthode hashcode() mais j'aurais surchargé les méthodes equals() et compareTo() de l'objet pour - au final - me servir de la méthode equals().

[guiom]

L'opérateur '==' effectue une comparaison sur les adresses des objets alors que la méthode equals() sert à vérifier si deux objets on un contenu identique ( dans le contexte ).

C'est pour ça que le comportement que j'ai m'étonne: si == vérifie les adresses, ne devrais-je pas avoir un comportement stable ?
car hashcode() renvoie l'équivalent de l'adresse à ma connaissance.

Info supplémentaire, j'ai testé mon code sur JDK 1.3 et 1.5, et le bug apparaît sur les 2 plateformes. Ce n'est donc pas un changement de spec de JVM qui provoque ce problème.

Personnellement, je n'aurais pas utilisé la méthode hashcode() mais j'aurais surchargé les méthodes equals() et compareTo() de l'objet pour - au final - me servir de la méthode equals().

Que mettre dans equals() ? pas this == o car c'est ce qu'il est fait par défaut dans equals(). Je peux y mettre this.hashcode() == o.hashcode() mais je ne vois pas ce que cela apporterait mis à part un code un peu plus propre...

[iohack]

Pour moi : non hashcode ne retourne pas d'adresse mais un identifiant unique qui peut être utilisé pour distinguer deux objets dont la méthode equals() retournerai true ( javadoc méthode hashcode de la classe java.lang.Object ). Je m'explique :
Admettant que tu ai une classe "MaClasse" contenant deux attributs "att1" et "att2" de type String.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class MaClasse{
   String att1;
   String att2;
   public boolean equals(Object o){
      MaClasse mc=(MaClasse)o;
      return mc.att1.equals(this.att1)&&mc.att2.equals(this.att2);
}

tu remarqueras que dans mon code je compare les deux attributs pour vérifier l'égalité.
La doc dit que si deux objets sont égaux ( méthode equals ), alors le hashcode devra être le meme pour ces deux objets.
Elle dit egalement qui si ces objets sont inégaux ( methode equals ), alors le hashcode pour quand-même etre identique pour les deux objets.
Concretement on pourrait faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
public int hashCode(){
   return this.att1.hashCode();
}

L'intérêt de tous est que l'on peut avoir plusieur "niveaux" d'égalité en fonction du contexte.

Pour l'opérateur '==' il s'agit de comparaison de référence : si deux objets de même classe sont créés dand deux "new" différents, alors cet opérateur retournera toujours faux ( dans notre exemple aussi même si les deux attributs ont une valeur identique : o1.equals(o2) ).

En espérant avoir été clair.

[guiom]

c'est tout à fait clair.

Et je suis d'accord avec ce que tu dis

Pour l'opérateur '==' il s'agit de comparaison de référence

Donc quand je fais "this == o" et que j'ai bien à faire aux 2 mêmes instances, ne devrais-je pas avoir toujours true ? là est mon problème.

Il a fallu que j'utilise hashcode() (non surchargé) pour que ça marche !

Mais je crois avoir trouvé à l'instant la réponse dans la javadoc de Object.equals() qui équivaut à ==. Il y est indiqué:

It is consistent: for any reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the object is modified.

C'est la fin qui me préoccupe, que je traduirais par "en supposant qu'aucune information utilisée par les comparaisons de equals() ne change". Vu que equals() équivaut à == dans Object, == réponds à ces critères...
Donc si les attributs de ma référence changent pendant la comparaison, il est normal que == ne ramène pas true.
Mais je trouve ça quand même bizarre... == n'est pas atomique ? autre erreur...