Discussion :

[Azhenot]

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 :

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

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.

[wax78]

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 :

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

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 :

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

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 :

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

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

[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 :

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

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 !

[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 :

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

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 :

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

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

[Laurent.B]

Bonjour,

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

[thelvin]

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.

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.

Bonjour,

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

Je constate une erreur dans cette FAQ

Code :

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

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.