Comparaison 2 String avec ==

Version imprimable

21/08/2013, 18h57
Azhenot

Comparaison 2 String avec ==
Bonjour,

On m'a toujours dit qu'il ne faut pas comparer 2 String avec "==" parce que ça compare les adresses.

Mais alors j'ai voulu tester et je tombe sur ça :
Code:

1 2 3 4 5 6 7 String ok = "ok"; String bonjour = "ok"; if( ok == bonjour) { System.out.println("ici"); }
Il m'envoie le message "ici".

Pourquoi ? Ce sont des adresses différentes.

Merci d'avance.

Citation:

Envoyé par Azhenot

ce sont des adresses différentes.

Ha bon ? Comment le sais tu ? :)

Je n'ai pas la réponse théorique, par contre en faisant 2 essai et en désassemblant le code j'ai remarqué que apparemment, les 2 strings ont la même adresses.

Test avec 2 fois ok.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    public static void main(String args[])
    {
        String ok = "ok";
    //    0    0:ldc1            #16  <String "ok">
    //    1    2:astore_1
        String bonjour = "ok";
    //    2    3:ldc1            #16  <String "ok">
    //    3    5:astore_2
        if(ok == bonjour)
    //*   4    6:aload_1
    //*   5    7:aload_2
    //*   6    8:if_acmpne       19
            System.out.println("ici");
    //    7   11:getstatic       #18  <Field PrintStream System.out>
    //    8   14:ldc1            #24  <String "ici">
    //    9   16:invokevirtual   #26  <Method void PrintStream.println(String)>
    //   10   19:return
    }

Test avec Ok et Ok1

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
        String ok = "ok";
    //    0    0:ldc1            #16  <String "ok">
    //    1    2:astore_1
        String bonjour = "ok1";
    //    2    3:ldc1            #18  <String "ok1">
    //    3    5:astore_2
        if(ok == bonjour)
    //*   4    6:aload_1
    //*   5    7:aload_2
    //*   6    8:if_acmpne       19
            System.out.println("ici");
    //    7   11:getstatic       #20  <Field PrintStream System.out>
    //    8   14:ldc1            #26  <String "ici">
    //    9   16:invokevirtual   #28  <Method void PrintStream.println(String)>
    //   10   19:return

donc a mon avis le compilateur il regarde les string hardcodé et il "optimise" niveau mémoire j'imagine. Mais c'est mon avis par essais/erreur.

Enfin sinon en gros, je pense que le compilo mets les 2 string dans une pool de string et il s'arrange pour pas avoir 2 fois le même string.

Tu peux aussi faire :

Code:

1
2
3
4
5
6
7
String ok = new String("ok");
		String bonjour = new String("ok");
 
		if( ok == bonjour)
		{
			System.out.println("ici");
		}

Et constaté que la le comportement à changé.

21/08/2013, 20h05
Azhenot
Oh ok donc vous pensez que c'est pour optimiser la mémoire.

C'est vrai que c'est pratique vu que l'on sait qu'un String est immuable.

Et avec StringBuffer effectivement ca ne fonctionne pas.
Code:

1 2 3 4 5 6 7 8 StringBuffer ok = new StringBuffer("ok"); StringBuffer bonjour = new StringBuffer("ok"); if( ok == bonjour) { System.out.println("ici"); }
Merci beaucoup !
21/08/2013, 20h30
joel.drigo
Salut,

une belle synthèse et explication du principe... désolé si l'anglais n'est pas votre fort ;)

Mais en gros, la théorie est que java optimise pour des raisons de performances, comme de mémoire, la création des instances de String lorsqu'on utilise l'affectation par constante, en utilisant un pool. En plus en cas de création par concénation, un StringBuilder est utilisé en interne, mais la chaîne affectée au final sera obtenue par la méthode intern() de String, donc venant du pool.

Ainsi, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 public static void main(String[] args) { String s1 = "hello"; String s2 = "h" + "e" + "l" + "l" + "o"; System.out.println(s1==s2); }
affichera true

et
Code:

1 2 3 4 5 6 7 8 9 10 public static void main(String[] args) { String s1 = "hello"; String s2 = new String("hello"); System.out.println(s1==s2); System.out.println(s1==s2.intern()); }
affichera :
false
true
22/08/2013, 00h14
Laurent.B

Bonjour,

Cf http://java.developpez.com/faq/java/...NG_comparaison

Citation:

Envoyé par joel.drigo

Mais en gros, la théorie est que java optimise pour des raisons de performances, comme de mémoire, la création des instances de String lorsqu'on utilise l'affectation par constante, en utilisant un pool.

En fait peu importe que ce soit pour affectation ou passage en paramètre. Autrement dit peu importe dans quelle expression elle apparaît.
En Java, toute expression constante String vient d'un pool.

Rappel de ce qu'est une constante. Une expression constante est une expression qui pourrait servir à définir une constante.

Citation:

Envoyé par joel.drigo

En plus en cas de création par concénation, un StringBuilder est utilisé en interne, mais la chaîne affectée au final sera obtenue par la méthode intern() de String, donc venant du pool.

Dans ce cas-là c'est le compilateur qui se charge de la concaténation. Peu importe qu'il le fasse avec un StringBuilder ou quoi. Au runtime, le programme ne sait pas qu'il y avait concaténation dans le code source.

Citation:

Envoyé par Laurent.B

Bonjour,

Cf http://java.developpez.com/faq/java/...NG_comparaison

Je constate une erreur dans cette FAQ
Code:

1 2 3 4 5 6 7 8 String a = "coucou"; String b = "coucou"; a==b; /** FAUX, a et b sont des instances différentes de String. * Ce résultat est théorique, car certains compilateurs pourraient optimiser * le code pour ne créer qu'une seule instance mémoire */
Cet exemple ne marche pas

Edit : ou peut-être qu'il était valide avant jdk 1.4, je ne trouve pas la doc. Mais ça commence à dater sévère.

a==b renverra toujours true et il n'y a rien de théorique, c'est imposé par Java.
Ils se sont tous les deux fait assigner une constante String, ces constantes viennent donc du pool, elles n'ont pas le choix. Vu qu'elles contiennent la même chose, le pool donnera la même String pour les deux.

Ce qui ne veut pas dire que faire a==b est une bonne idée. Il ne faut pas, parce qu'en général quand on compare des String on ne sait pas si elles viennent du pool ou pas. (Plus exactement, en général il y en a au moins une qui ne vient pas du pool.)
L'exemple n'illustre pas bien.

22/08/2013, 11h10
joel.drigo
Citation:

Envoyé par thelvin

Dans ce cas-là c'est le compilateur qui se charge de la concaténation. Peu importe qu'il le fasse avec un StringBuilder ou quoi. Au runtime, le programme ne sait pas qu'il y avait concaténation dans le code source.

J'aurais dû m'en douter. Au temps pour moi.

Pour la faq, je me demandais si ce n'était pas le cas avant java 1.4 (version par laquelle j'ai commencé), et que la faq n'avais tout simplement pas été mise à jour.

Question qui m'intrigue (même si je proscris évidemment l'usage du == pour comparer des instances, String ou pas) : si le programme suivant affiche true en 1.6, alors que le substring ne crée pas de nouvelle chaîne et retourne une "sous partie" de s2, avec un offset et une longueur (sauf en 1.7 d'après ce que j'ai compris, ou une nouvelle chaîne serait systématiquement créée), quelle mécanisme entre en jeu ici ? C'est par l'invocation de intern() que le pool va être interrogé ?
Code:

1 2 3 4 5 6 7 8 public static void main(String[] args) { String s0 = "hel"; String s1 = "hel"; String s2 = s0 + s1; System.out.println(s2.substring(0,3).intern()=="hel"); }
22/08/2013, 11h33
tchize_

oui. La méthode intern() de String te retrourne une instance de String, ayant le même contenu que la String d'origine, mais pour laquelle tu as la garantie que deux String avec le même contenu appelant intern() retourneront la même instance.
22/08/2013, 11h40
thelvin

Et pour information, substring(), si la taille demandée n'est pas la même que la taille originale, crée toujours une nouvelle String.

La différence entre 1.7 et avant, c'est qu'avant 1.7, la String créée avec substring() partageait le char[] interne de la String qui a servi à la créer, ce qui évite de créer un nouveau char[] et de dupliquer son contenu.
Depuis 1.7 substring() ne partage plus ce char[] entre les deux String, la nouvelle String a toujours son propre char[].

La raison en était, je pense, qu'on utilise souvent substring() sur des String gigantesques dans le but d'en extraire et conserver de toutes petites parties.
Avant 1.7, ce cas-là fait qu'on garde en mémoire, inéligible à la garbage-collection, le gigantesque char[] auquel font référence les petites String, bref cela occupe beaucoup de mémoire pour rien et ne la libère pas.
Cela peut être évité en faisant new String(grandeString.substring(start, end)), la création avec new String() déclenchant une duplication du char[]. Mais il fallait le savoir, ce n'est pas documenté, au contraire la JavaDoc disait que new String(String) ne sert à rien. Souvent ce n'est pas fait.
Depuis 1.7, le problème ne se pose pas car le char[] interne n'est plus partagé, substring() en crée un nouveau de la bonne taille, et le gigantesque char[] est garbage-collecté dès que l'extraction est finie. Et new String(String) ne sert bel et bien plus à rien.
Par contre depuis 1.7, si la String de départ n'est pas si grande, on se retrouve à dupliquer en pagaille des char[] au contenu quasi-identique, pour rien. Le tradeoff a été jugé bon.
22/08/2013, 11h44
tchize_

Citation:

Envoyé par thelvin

La raison en était, je pense, qu'on utilise souvent substring() sur des String gigantesques dans le but d'en extraire et conserver de toutes petites parties.

Ce qui est typique des parseurs XML :) Tu te retrouvais à stocker des attribut de 10 caractère qui pointaient vers un char[] de 64K :calim2:
22/08/2013, 11h48
joel.drigo

Citation:

Envoyé par thelvin

Et pour information, substring(), si la taille demandée n'est pas la même que la taille originale, crée toujours une nouvelle String.

La différence entre 1.7 et avant, c'est qu'avant 1.7, la String créée avec substring() partageait le char[] interne de la String qui a servi à la créer, ce qui évite de créer un nouveau char[] et de dupliquer son contenu.
Depuis 1.7 substring() ne partage plus ce char[] entre les deux String, la nouvelle String a toujours son propre char[].

C'est ce que j'avais compris. Je me suis mal exprimé en parlant de "ne créé pas de nouvelle chaîne" : je parlais bien du char[] interne.
22/08/2013, 11h51
adiGuba

Citation:

Envoyé par joel.drigo

C'est ce que j'avais compris. Je me suis mal exprimé en parlant de "ne créé pas de nouvelle chaîne" : je parlais bien du char[] interne.

Mais le fait que le char[] interne soit identique n'a aucun impact sur le résultat de l'opérateur == entre deux String ;)

a++
22/08/2013, 11h53
joel.drigo

Citation:

Envoyé par adiGuba

Mais le fait que le char[] interne soit identique n'a aucun impact sur le résultat de l'opérateur == entre deux String ;)

a++

euh, j'ai jamais dit ça.
22/08/2013, 12h01
adiGuba

Citation:

Envoyé par joel.drigo

euh, j'ai jamais dit ça.

Ah c'est ce que je pensais avoir compris dans ton précédent message... :oops:

M'enfin, hormis sur les enum, l'opérateur == ne devrait pas servir pour la comparaison mais uniquement pour l'identité ;)

a++
22/08/2013, 12h04
joel.drigo

Sans vouloir flooder :oops:

à partir du moment ou une instance de String stocke la chaine dans un char[], et que celle produit par substring utilise le même char[], je me demandais comment méthode native intern() pouvais retourner au final la même instance que la constante à laquelle je la comparais. C'est vrai que je prends parfois des raccourcis dans mes expressions qui peuvent porter à confusion.
22/08/2013, 12h56
tchize_
a mais non. La substring retournera, via intern, une instance différent. intern() ne se base pas sur le char[] mais uniquement sur la valeur de la String (char[] + index de début et fin) ;) L'algo, basiquement, ressemble à ça (mais en optimisé hein)
Code:

1 2 3 4 5 6 7 8 intern(){ for (String s: stringInternes) if (s.equals(this)) return s; return stringInternes.add(new String(this)); }