Bonjour
 
J'ai fait un petit programme auquel je ne comprend rien du tout.  
 

 
Quand je lance ce programme j'obtiens:
 

 
Pourquoi, avec l'auto-unboxing y'a égalité entre -128 et +127 (càd le domaine de définition du type byte) et plus en dehors ? Si vous avez des pointeurs sur des docs qui expliquent cela je suis preneur... Merci d'avance

http://www.owasp.org/index.php/Java_gotchas
C'est une histoire d'optimisation pour les petites valeurs, souvent employées:

A+,

Au risque de dire une connerie énorme, mais bon j'suis plus à ca pret: on est d'accord que == teste l'égalité entre pointeurs vu que Integer est un objet, donc le résultat du test dépend de la facon dont la JVM fonctionne.

Donc à mon avis: ta JVM stocke les pointeurs sur les x entiers possibles du type byte (-128 à +127) pour une raison quelconque (optimisation interne ou autre, on peut imaginer que ces nombres-là sont les plus utilisés donc ya des mécanismes spéciaux pour optimiser leur utilisation) mais pas plus que ca pour une autre raison quelconque (par exemple créer tous les entiers possibles ca prendrait de la place pour rien). Et elle utilise ces pointeurs automatiquement quand "toi le programmeur" tu te sers de ces nombres. Bonne chance pour trouver de la doc là-dessus si c'est bien JVM-dépendant.

Maintenant histoire de troller un peu, j'ai envie de dire que je vois pas trop de cas où ca a un intéret de comparer les pointeurs d'objets Integer... Mais du coup c'est intéressant, si tu en as un sous la main, on peut p'tetre en discuter.

Edit:   et en mieux expliqué et plus court... Cela dit j'avais vu juste

A la base, comme il a une classe, s'il veut comparer des objets, il faut faire appel aux méthodes ad-hoc de la classe, donc equals ici, et non pas ==.
A+,

Il est rare que comparer des refs ait le moindre intérêt (sauf à les comparer avec null à la limite), mais dans la mesure où l'utilisateur (du langage) doit pouvoir customiser son test d'égalité et où les designers de java ont déclaré que l'overloading d'opérateurs par l'utilisateur était anathème, ben tu te retrouves à devoir utiliser equals() pour les tests d'égalité.

deux choses :
- primitives != wrapper
- l'utilisation directement de primitives dans ton cas est préférable car il existe des effets de bord a l'autoboxing/unboxing
 
http://www.javabeat.net/articles/3 [...] -50-2.html

Merci pour ces réponses. Je ne comprends toujours pas la raison du choix de cette limite (plage d'un byte) mais bon, on va faire avec. Ce qui me gêne le plus (et qui a été mentionné) c'est le comportement variable de == en fonction de la valeur de ce qu'on compare. Je préférerais que ça ne marche jamais ou toujours, mais là ça me laisse perplexe..  
 
Merci encore de votre aide
 

Le comportement n'est pas variable, il répond effectivement correctement selon que l'objet de la classe Integer est le même ou non, et l'implémentation fait que pour des valeurs entre -128 et +127, il n'y a qu'un seul objet de la classe Integer de créé.
 
Si vous vouliez comparer les valeurs des objets en question, il fallait utiliser la méthode ad-hoc précisée dans la classe Integer, ie equals:
Integer x1 = 124;
Integer x2 = 124;
while (x1.equals(x2))...
Et si vous tenez a utiliser ==, il fallait utiliser des types primitifs et non des classes:
int x1 = 124;
int x2 = 124;
while (x1 == x2)...
 
A+,