Discussion :

[ruana]

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 :

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

1
2
3
4
 
String s1 = "s";
String s2 = "s";
System.out.println(s1 == s2);

"true" s'affiche.

Code :

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

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

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 :

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

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

"true" s'affiche.

Code :

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

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

"false" s'affiche

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,

[Sanguko]

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.

[jibbi]

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 :

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

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

[Napalm51]

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.

[adiGuba]

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.

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 :

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

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


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 :

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

if (obj==this) return true;

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


a++

[ruana]

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