Discussion :

[0redd]

Bonjour
Voilà je voudrais savoir si correcte de faire celà

Code :

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

1
2
3
4
5
6
 
Integer i = 4;
Integer j = 4;
if( i == j ) {
   ...
}

j'ai lu que le compilateur pour gagné de la mémoire, créera juste une instance et donc i et j référence le même objet (4), et là l'égalité marche puisqu'on compare les référence,
mais pourrai-t'on dire que c'est toujours le cas?
et puis si on trouve cela dans un code, on devra toujours voir la déclaration de l'integer, car quand j'essaye, celà crée deux objets distinct ..

Code :

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

1
2
3
4
5
6
 
Integer i = new Integer(4);
Integer j = Integer(4);
if( i == j ) {
   ...
}

equals serai plus approprié dans ce cas ci??
merci d'avance

[Heimdal]

J'ai pas vraiment compris la question mais tes remarques sont justes.

[0redd]

si on trouve i == j, on ne pourra pas dire si ça retourne true ou false?
et puis ça risque de changé d'une machine virtuelle à une autre?
et puis c'est le compilateur qui fait les optimisations?

[Alain Defrance]

Salut,

Si ma mémoire est bonne c'est pas le compilateur qui fait ça mais le JRE (d'où la questions à se poser si c'est portable d'une JVM à l'autre).

Bref entrons dans le vif du sujet. La JVM utilise le pattern flyweight pour effectivement faire des économies de mémoire :

Code :

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

1
2
Integer i = 4;
Integer j = 4;

Maintenant si tu n'utilise plus de littéraux, et que tu explicite une nouvelle allocation alors tu as deux instances (en faire 3 avec le littéral).

Code :

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

1
2
Integer i = new Integer(4);
Integer j = new Integer(4);

Certainement que ce billet sur mon blog t'intéresseras : http://alaindefrance.wordpress.com/2...epresentation/ (en anglais)

[0redd]

c'est la jvm qui fait celà?
la jvm ne fait pas qu'exécuter le byte code?
sinon merci pour votre réponse

[thelvin]

Alors, des précisions, tirées des JLS :

- C'est en partie le compilateur, en partie la JVM qui font ça. Le compilateur ne peut pas instancier d'objet, et il n'a nulle part d'où référencer des Integer connus (seules les String ont un traitement particulier pour ça.) Mais il est tenu d'utiliser une instruction d'auto-inbox qui garantit que la JVM le fera correctement. (Je suppose qu'en pratique, c'est un appel à Integer.valueOf(), qui doit être considéré tenu d'implémenter ce comportement. Auquel cas, c'est aussi la bibliothèque de base qui le fait.)

- Cela ne dépend pas quelle JVM utilisée : c'est dans les JLS, ça doit faire ça sinon c'est non-conforme.

- Ce comportement est garanti pour les entiers de -128 à 127, mais pas pour les autres. Pour les autres, c'est bel et bien au choix de la JVM (et donc probablement de la bibliothèque de base.)


Remarquons aussi qu'à partir du moment où on utilise le mot-clé new, on crée forcément une nouvelle instance. Il le garantit. C'est même à peu près ce à quoi il sert.
(Bon, sauf si ça lance une exception, auquel cas il n'y a pas d'instance du tout, nouvelle ou pré-existante.)

Edit :

c'est la jvm qui fait celà?
la jvm ne fait pas qu'exécuter le byte code?

Techniquement si. Mais si on fait un abus de langage et qu'on veut dire JRE au lieu de JVM (la JRE étant la JVM, la bibliothèque de base, et quelques programmes exécutables en ligne de commande)...
Si on parle de JRE au lieu de JVM, donc, ça marche :
la JVM exécute le bytecode, et le bytecode en question est un appel à la bibliothèque de base qui se charge de faire l'auto-inbox.

(Après essai, le compilateur d'Eclipse fait bel et bien un appel à Integer.valueof(int))

[0redd]

Ce comportement est garanti pour les entiers de -128 à 127, mais pas pour les autres. Pour les autres, c'est bel et bien au choix de la JVM (et donc probablement de la bibliothèque de base.)

Quel comportement?
la bibliothèque de base? (c'est quoi) ?
sinon merci pour vos éclaircissement

[thelvin]

Quel comportement?

Le fait que

Code :

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

1
2
3
Integer i = 4;
Integer j = 4;
System.out.println(i == j);

Affiche toujours true.
C'est garanti pour 4, et c'est garanti pour tous les nombres de -128 à 127.
Mais pour les autres, ça dépend de l'implémentation. Apparemment, de l'implémentation de la classe java.lang.Integer, d'après mes tests.

la bibliothèque de base? (c'est quoi) ?

Toutes les classes fournies de base par Java, consultables dans la JavaDoc.
Exemples : Integer, String, List, Date, DateFormat, tout ce qui est fourni de base.


Edit: En résumé : Ça ne marche pas forcément pour tous les nombres, et la règle n'est donc pas totalement évidente.
À mon avis il vaut mieux éviter de compter dessus, et ne pas essayer de se rappeler si ça va marcher pour le nombre qu'on est en train de manipuler.

[0redd]

Mercii , oui , j'utiliserai à la place equal, elle au moins elle retourne toujours un résultat correcte ^^, sinon le truc de -128, 127 c'est dit ou??

[thelvin]

sinon le truc de -128, 127 c'est dit ou??

ici, notamment la partie :

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Cela se voit aussi :
- en constatant que l'auto-inbox est effectué avec un appel à Integer.valueOf(int). Ce qui peut se faire en désassemblant une classe qui fait un auto-inbox.
- en lisant le code source de Integer.valueOf(int) du JDK officiel. Il est assez clair.

[0redd]

Merci j'y vois beaucoup plus clair là ^^