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