Discussion :

[smutmutant2003]

Bonjour

String literals are created at compile time, and the compiler does not create a duplicate String literal. The strings with the new operator are created at runtime, and a new string will be created even if there is an identical string already in the pool created at compile time.

je dois passer une certif bientôt, et il y a quelque chose qui m'échappe. Comment peut on faire la différence entre la compilation, et le runtime. J'avoue que c'est une notion qui m'échappe encore.. C'est souvent face à ce genre de question que je sèche. Alors je ne sais pas si c'est basique où pas, en tout cas, je suis convaincu, qu'il se trouvera des personnes pour connaître la réponse.

Bien à vous.

[ok.Idriss]

Salut.

J'avais appris que le Java était d'abord compilé en bytecode qui lui était ensuite interprété (exécuté donc, d'où le terme de runtime) par le JRE (une machine virtuelle, le Java Runtime Environement).

Sauf qu'il n'y a pas longtemps j'ai vaguement entendu parler du JIT (Just-in-time) sur les nouvelles JVM (Java virtual machine) ... Enfin bref, d'autres sauront surement t'en dire plus, et tu peut te renseigner dessus à l'aide d'une recherche.

En espérant t'avoir aidé.

[thelvin]

J'avais appris que le Java était d'abord compilé en bytecode qui lui était ensuite interprété (exécuté donc, d'où le terme de runtime) par le JRE (une machine virtuelle, le Java Runtime Environement).

Précisément.

Le compile-time c'est le moment où on transforme les fichiers code source .java en fichiers binaires .class, contenant le bytecode compilé.

Le runtime c'est le moment où le programme est exécuté, en utilisant les fichiers .class. À ce moment-là, le code source n'est plus utilisé.

En ce qui concerne le JIT, c'est juste la manière utilisée pour exécuter du Java avec de bonnes performances. Ça ne nous regarde pas, la manière employée. Le runtime, c'est le runtime, point.

[smutmutant2003]

Bonjour et merci pour vos réponses.
Dans la définition chez Sun j'ai :

String literals are created at compile time, and the compiler does not create a duplicate String literal. The strings with the new operator are created at runtime, and a new string will be created even if there is an identical string already in the pool created at compile time.

Finalement je ne comprend plus, donc une chaine est crée pendant la compilation
quand je fais String c="unechaine";
En gros en faisant javac classe.java. donc dans le .class
Et une autre chaine est crée en fait en faisant lorsque je fais
String x = new String("qqch");
java classe.class ?
Je ne comprend pas vos réponse, c'est pas trés claire pour moi.
Auriez vous un schéma pour illustrer ce que vous dîtes ?

Bien à vous.

[hibour]

Je te traduit ton texte:
Quand tu crée un String en l'affectant à un litteral alors le compilateur crée une et une seule instance. càd

Code :

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

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

Les références s1 et s2 sont identique (s1 == s2) car le compilateur affecte la même référence aux 2 variables (D'où le pool: littérals <-> références String).
Sinon: Quand tu crée un String avec un new càd

Code :

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

String s = new String("abc");

Le compilateur crée cette référence à l'exécution et n'attribue pas l'adresse à la compilation..

[thelvin]

String x = new String("qqch");

Ça, la plupart du temps c'est une aberration. Mais en résumé, il y a deux objets String dans cette ligne.

D'abord l'objet String créé à la compilation du fait d'avoir utilisé le littéral "qqch".

Ensuite, un autre objet String, créé au runtime, qui contient aussi le texte qqch, et qui est créé du fait du mot-clé "new."

En général ça ne sert à rien. On devrait logiquement faire String x = "qqch";

Quand on appelle le constructeur d'une classe, avec "new" donc, on crée toujours un nouvel objet. En fait c'est exactement ce que veut dire un constructeur. Mais on n'a pas toujours besoin de le faire. Avec les String c'est même rare.
L'intérêt de faire new String("qqch") est mince. En gros, ça crée un objet String, qui contient le texte qqch, mais qui renvoie false si on le compare à "qqch" ou à n'importe quel objet autre que lui-même.

Pour illustrer :

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
19
20
21
22
23
24
String s1 = "qqch";
String s2 = new String("qqch");
 
if(s1 == "qqch") {
  System.out.println("s1 et 'qqch' sont identiques.");
}
if(s2 == "qqch") {
  System.out.println("s2 et 'qqch' sont identiques.");
}
if(s1 == s2) {
  System.out.println("s1 et s2 sont identiques.");
}
if("qqch" == "qqch") {
  System.out.println("'qqch' et 'qqch' sont identiques.");
}
if(s1.equals("qqch")) {
  System.out.println("s1 et 'qqch' sont égaux.");
}
if(s2.equals("qqch")) {
  System.out.println("s2 et 'qqch' sont égaux.");
}
if(s1.equals(s2)) {
  System.out.println("s1 et s2 sont égaux.");
}

On voit que s1 et s2 contiennent la même chose, mais sont des objets différents. De plus, s1 est l'objet créé à la compilation avec le littéral "qqch".

[smutmutant2003]

Le compilateur crée cette référence à l'exécution et n'attribue pas l'adresse à la compilation..

Un objet n'importe qu'elle qu'il soit, ne réside-t-il pas sur le tas ? où Heap en anglais.
Hibour voudriez vous dire qu'il éxiste deux tas ? Un pendant la compilation, et l'autre pendant l'éxécution ?
Ca complique les choses pour les String ..

[dinobogan]

Ça, la plupart du temps c'est une aberration. Mais en résumé, il y a deux objets String dans cette ligne.

D'abord l'objet String créé à la compilation du fait d'avoir utilisé le littéral "qqch".

Ensuite, un autre objet String, créé au runtime, qui contient aussi le texte qqch, et qui est créé du fait du mot-clé "new."

En général ça ne sert à rien. On devrait logiquement faire String x = "qqch";

Quand on appelle le constructeur d'une classe, avec "new" donc, on crée toujours un nouvel objet. En fait c'est exactement ce que veut dire un constructeur. Mais on n'a pas toujours besoin de le faire. Avec les String c'est même rare.
L'intérêt de faire new String("qqch") est mince. En gros, ça crée un objet String, qui contient le texte qqch, mais qui renvoie false si on le compare à "qqch" ou à n'importe quel objet autre que lui-même.

Pour illustrer :

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
19
20
21
22
23
24
String s1 = "qqch";
String s2 = new String("qqch");
 
if(s1 == "qqch") {
  System.out.println("s1 et 'qqch' sont identiques.");
}
if(s2 == "qqch") {
  System.out.println("s2 et 'qqch' sont identiques.");
}
if(s1 == s2) {
  System.out.println("s1 et s2 sont identiques.");
}
if("qqch" == "qqch") {
  System.out.println("'qqch' et 'qqch' sont identiques.");
}
if(s1.equals("qqch")) {
  System.out.println("s1 et 'qqch' sont égaux.");
}
if(s2.equals("qqch")) {
  System.out.println("s2 et 'qqch' sont égaux.");
}
if(s1.equals(s2)) {
  System.out.println("s1 et s2 sont égaux.");
}

On voit que s1 et s2 contiennent la même chose, mais sont des objets différents. De plus, s1 est l'objet créé à la compilation avec le littéral "qqch".

Tu devrais également mettre la trace écrite par ton programme, car à la première lecture, je pensais que tu ne comprenais rien à la gestion des String en Java. A la seconde lecture, j'ai compris que tu avais compris
Donc ajoute le résultat du programme pour que ce soit bien clair pour tout le monde

[hibour]

En java tous les objets réside dans le heap à part les arguments d'une méthode appelé qui eux sont dans la pile si je ne me trompe pas.
Le code généré va faire en sorte d'allouer une seule fois les littérals (Pool) c'est tout ce que je peux te dire.

[Uther]

A noter qu'il le fait quand il peut le faire simplement mais il n'y a pas de garantie absolue qu'il le fasse. Donc, il faut toujours garder a l'esprit qu'un comparaison entre string n'est pas fiable.

Si on veut l'obliger a utiliser le pool de string, il faut utiliser intern() .

[smutmutant2003]

Ça, la plupart du temps c'est une aberration.
En général ça ne sert à rien. On devrait logiquement faire String x = "qqch";
Avec les String c'est même rare.
L'intérêt de faire new String("qqch") est mince.

Thelvin vous parlez à un convaincu, je vais même rajouter, que je n'ai jamais dans ma carrière de programmeur utiliser un new String("qqch");
Si c'était pas les exams de type scjp, pour nous emmerder, et que je dois passer trés bientôt, je n'aurai jamais posé ce genre de question. C'est pas avec ces kholes que l'on peut juger un programmeur, loin s'en faut, mais que voulez vous .

Toutefois je pense avoir compris vos réponses. Je vous remercie tous pour vos contributions.

[Baptiste Wicht]

Pour le constructeur de String, il a une utilité : http://blog.developpez.com/adiguba/p...string-string/

En java tous les objets réside dans le heap à part les arguments d'une méthode appelé qui eux sont dans la pile si je ne me trompe pas.
Le code généré va faire en sorte d'allouer une seule fois les littérals (Pool) c'est tout ce que je peux te dire.

En fait en Java pour le moment (avant Java 7 et son escape-analysis) , seules les variables de type primitif et les références vers les paramètres (pas les valeurs elles-mêmes, seulement les paramètres) et les références vers les variables locales sont sur la pile.

[thelvin]

Pour le constructeur de String, il a une utilité : http://blog.developpez.com/adiguba/p...string-string/

Yup, mais ça ne s'applique pas aux littéraux. Et puis, ça reste un cas qui ne s'applique que dans des cas d'utilisations assez précis.

[hibour]

.. seules les variables de type primitif et les références vers les paramètres (pas les valeurs elles-mêmes, seulement les paramètres) et les références vers les variables locales sont sur la pile.

Je n'ai jamais dit qu'on met la valeur de l'objet dans la pile , Comme le passage de paramètres des objets se fait par référence alors c'est une évidence qu'on transmet que la référence via la pile..
A++

[hibour]

A noter qu'il le fait quand il peut le faire simplement mais il n'y a pas de garantie absolue qu'il le fasse. Donc, il faut toujours garder a l'esprit qu'un comparaison entre string n'est pas fiable.

Si on veut l'obliger a utiliser le pool de string, il faut utiliser intern() .

Si c'est fiable même des littéral qui sont déclarer dans deux classes distinctes (chargé par le même ClassLoader).