2017-09-01 4 views
3

J'essaie de comprendre le comportement du code ci-dessous lorsque les opérateurs de comparaison numérique sont utilisés pour comparer 2 objets entiers en Java.Java autoboxing et la comparaison des objets en utilisant les opérateurs

Integer i1 = new Integer(1); 
    Integer i2 = new Integer(1); 
    System.out.println(i1 == i2); 
    System.out.println(i1 > i2); 
    System.out.println(i1 >= i2); 

sortie du code ci-dessus est:

false 
false 
true 

Je comprends ce qui se passe dans le 1er cas (la comparaison de l'instance d'objet est fait c'est pourquoi il donne de faux). Mais pourquoi les deuxième et troisième scénarios sont-ils différents et comment cela fonctionne-t-il exactement?

+0

Je suis confus par votre résultat. Je pensais que «Integer» dans la gamme -128 à 127 ont été requis par le JLS pour être mis en cache et le même objet. https://stackoverflow.com/questions/20897020/why-integer-class-caching-values-in-the-range-128-to-127 – markspace

+0

@markspace Uniquement lors de l'autoboxing ou de l'appel de 'valueOf()'. Les objets créés avec le mot clé 'new' doivent toujours être distincts. – shmosel

+0

@shmosel Ah, c'est vrai! La question SO à laquelle je suis lié dit "boxed" objet. Merci de le signaler. – markspace

Répondre

4

Parce que <, >, >= et <= sont comparaison numérique, et donc, le compilateur sait qu'il doit faire unboxing.

Cependant, == et != fonctionnent toujours comme des comparateurs de référence pour les types non-primitifs.

+0

La promotion numérique binaire (conversion en numérique) est effectuée sur les opérandes <, <=, >, et> = comme spécifié dans ([JLS 15.20.1] (https://docs.oracle.com/javase/specs/jls/se8/html/ jls-15.html # jls-15.20.1)) pour le 2ème et 3ème scénario. Cependant, dans le cas de! = Et ==, au moins un des opérandes doit être de type numérique pour que la promotion ait lieu. – ayushi