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.

[joel.drigo]

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 :

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

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");
 
	}

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

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

[tchize_]

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

[joel.drigo]

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.

[adiGuba]

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

[joel.drigo]

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.

[adiGuba]

euh, j'ai jamais dit ça.

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



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


a++

[joel.drigo]

Sans vouloir flooder

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

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

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

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));
}