Equals VS == ?

Bonjour à tous,

Je viens vers vous pour m'éclairer sur un point qui me semble étrange.
Je précise que je travaille avec Tiger (1.5)

Avec le code suivant :

Code:

---

1 2 3 4

String s1 = "s"; String s2 = "s"; System.out.println(s1 == s2);

---

"true" s'affiche.

Code:

---

1 2 3 4

String s1 = new String("s"); String s2 = new String("s"); System.out.println(s1 == s2);

---

Cette fois j'ai un false qui s'affiche 8O

Pensant que c'etait un mécanisme propre aux String, j'ai décidé de tester avec un Object qui permet l'autoboxing à savoir la classe Integer. Le résultat est le même :

Code:

---

1 2 3 4

Integer i1 = 1; Integer i2 = 1; System.out.println(i1 == i2);

---

"true" s'affiche.

Code:

---

1 2 3 4

Integer i1 = new Integer(1); Integer i2 = new Integer(1); System.out.println(i1 == i2);

---

"false" s'affiche :aie:

Je pensais que "==" comparer les variables d'instances de s1 et s2.
Quelqu'un peut m'expliquer le mécanisme qui justifierait ce comportement?

Merci d'avance.

Bien Cordialement,

Les string
Afin d'éviter la multiplication des string ayant le meme contenu, qui peut se produire en particulier parce que les string sont non mutables, java gère un pool de string. Dans ce pool vont être conservées toutes les string constantes et les litteraux par exemple.
C'est ce qui se passe dans ton premier exemple. La chaine "s" est dans le pool, et donc s1 et s2 pointent vers la meme reference. La "mise en pool" est faite à la compilation dans ce cas.
Dans le deuxieme cas, tu construis explicitement des strings. Les references sont donc différentes. Si tu veux utiliser le pool à l'execution, tu peux utiliser la methode String.intern()
Par exemple (ca n'a aucun interet, c'est juste pédagogique) :
String s1 = new String("s").intern();
String s2 = new String("s").intern();
Et tu as : s1==s2

Les integer
Je crois que donc le cas des integers, c'est un peu différent, puisque c'est l'outboxing qui entre en jeu. Le nombre 1 est transformé en objet Integer automatiquement. La transformation est faite assez intelligement pour ne pas recréer une nouvelle instance d'Integer à chaque nouveau nombre.

Salut,

L'autoboxing utilise les mêmes instances pour certaines valeurs.
C'est le cas pour les Booleans et les Bytes.

Pour ce qui est des Integers, l'autoboxing revoie les mêmes instances pour les valeurs entre -128 à 127 seulement.

Donc:

Code:

---

1 2 3 4 5 6 7 8

Integer i1 = 1; Integer i2 = 1; System.out.println(i1 == i2); // affiche true   i1 = 130; i2 = 130; System.out.println(i1 == i2); // affiche false

---

Enfin, de façon plus générale, l'opérateur "==" compare les références, alors que les méthodes equals (et equalsIgnoreCase pour String) comparent le contenu de l'objet.

Salut,

Citation:

---

Envoyé par jibbi

L'autoboxing utilise les mêmes instances pour certaines valeurs.
C'est le cas pour les Booleans et les Bytes.

Pour ce qui est des Integers, l'autoboxing revoie les mêmes instances pour les valeurs entre -128 à 127 seulement.

---

En effet l'autoboxing utilise les méthodes static valueOf() des classes wrappers correspondantes, mais le cache n'est pas obligatoire !

Dans la javadoc il est indiqué ceci :

Citation:

---

this method is likely to yield significantly better space and time performance by caching frequently requested values

---

:arrow: il n'y a aucune restriction/obligation sur le cache donc cela pourrait dépendre de la JVM. Il ne faut pas se baser dessus.


Ainsi si la JVM de Sun cache bien les valeurs entières entre -128 et 127, cela pourrait être différent avec d'autres JVM...


:arrow: Pour comparer les valeurs il faut utiliser equals() quoi qu'il arrive et ne pas se baser sur un éventuel cache.


A noter quand même que les méthodes equals() commence généralement par le code suivant :

Code:

---

if (obj==this) return true;

---

:arrow: Ce qui permet d'éviter la comparaison des données si on est sur la même référence ;)


a++

Bonjour à tous et merci pour vos réponses.

Pour situer le contexte, je dois passer la certification SCJP 1.5 et ce qui me bloque c'est cette notion de "cache"

Comment, lors de mon examen, je vais considérer qu'il a mis en cache les deux strings? Le comportement est t'il toujours le même?

Me concernant, lorsque je dois comparer deux String j'utilise toujours la méthode equals ou equalsIgnoreCase mais les questions de l'examen jouent justement sur l'ambiguité de ces méthodes et le '=='. Je n'arrive pas à trouver une régle qui me donnera à coup sur le comportement de la JVM.

Pour quoi s1 et s2 pointeraient vers la même instance lorsque je les instancie avec "s" plutot que new String("s") ? Ce n'est qu'un raccourci d'écriture pourtant.

Désolé d'être un peu pointilleux mais je suis un peu perdu la :?

Il me semble qu'un post pas si vieux que ça traitait d'un problème équivalent.
Je ne suis pas SCJP, mais de mémoire, et comme expliqué ci-dessus, les String entrées "en dur" dans le code sont chargé dans un pool de String par la JVM, et non pas crées dynamiquement quand on en a besoin. Afin de ne pas surcharger le pool, si deux chaînes codées en dur sont identiques, la JVM ne va créer qu'une seule instance. Alors que dans le cas d'un new String("..."); tu lui indique de créer une nouvelle instance, "==" te renvoi alors logiquement faux, les références n'étant pas les même.

Citation:

---

Envoyé par ruana

Pour quoi s1 et s2 pointeraient vers la même instance lorsque je les instancie avec "s" plutot que new String("s") ? Ce n'est qu'un raccourci d'écriture pourtant.

---

Les String sont un cas à part : les "String literals" font partie intégrante du langage et il est précisé dans les spécifications que deux même valeur pointent vers la même référence :
http://java.sun.com/docs/books/jls/t...al.html#3.10.5


Donc lorsque tu fais ceci :

Code:

---

1 2	String s1 = "s"; String s2 = "s";

---

Tu n'as qu'un seul objet en mémoire...


Mais lorsque tu fais ceci :

Code:

---

1 2	String s1 = new String("s"); String s2 = new String("s");

---

Tu en as 3 : le String literal "s" initial et les deux copie créé par les appels au constructeur...


a++

Merci beaucoup.
C'est désormais clair :D