ejemplos - Pregunta de Java sobre el autoboxing y la igualdad/identidad de objetos

autoboxing java

Question

Esta pregunta ya tiene una respuesta aquí:

• Weird Integer boxing en Java 10 respuestas

public class Main { 
    /** 
      * @param args the command line arguments */ 
    public static void main(String[] args) { 
        // TODO code application logic here
        int a1 = 1000, a2 = 1000; 
        System.out.println(a1==a2);//=>true 
        Integer b1 = 1000, b2 = 1000;
        System.out.println(b1 == b2);//=>false 
        Integer c1 = 100, c2 = 100; 
        System.out.println(c1 == c2);//=>true 
    }

}

¿Por qué es b1 == b2 falso y c1 == c2 verdadero?

Answer 1

Debido a que Integer es para algunos números bajos como enumeración, siempre hay la misma instancia. Pero los números más altos crean nuevas instancias de Integer y el operador == compara sus referencias

Answer 2

La respuesta que quieres está here

Answer 3

Las respuestas correctas ya han sido dadas. Pero solo para sumar mis dos centavos:

Integer b1 = 1000, b2 = 1000;

Este es un código horrible. Los objetos deben inicializarse como Objetos a través de constructores o métodos de fábrica. P.ej

 // let java decide if a new object must be created or one is taken from the pool
Integer b1 = Integer.valueOf(1000);

o

 // always use a new object
 Integer b2 = new Integer(1000);

Este codigo

Integer b1 = 1000, b2 = 1000;

por otro lado implica que el Integer era un primitivo, que no lo es. En realidad lo que estás viendo es un atajo para

Integer b1 = Integer.valueOf(1000), b2 = Integer.valueOf(1000);

y Integer solo agrupa objetos de -127 a 127, por lo que creará dos nuevos Objetos en este caso. Entonces, aunque 1000 = 1000, b1! = B2. Esta es la razón principal por la que odio el auto-boxeo.

Answer 4

Lee this

Java usa una agrupación para Integer en el rango de -128 a 127.

Eso significa que si creas un Integer con Integer i = 42; y su valor está entre -128 y 128, no se crea ningún objeto nuevo, pero se devuelve el correspondiente del conjunto. Es por eso que c1 es de hecho idéntico a c2 .

( Supongo que sabe que == compara referencias, no valores, cuando se aplica a objetos ).

Answer 5

Puedes encontrar la respuesta aquí:

Característica más extraña del lenguaje en la sexta respuesta.

Edit: lo siento no exatly la respuesta. El punto es que == compara referencias, no valores cuando lo usas con Integer. Pero con int "==" significa iguales.

Answer 6

Si el autounboxing hubiera funcionado también al realizar la comprobación de igualdad con el operador ''=='', podría escribir:

    Long notNullSafeLong1 = new Long(11L)
    Long notNullSafeLong2 = new Long(22L)
    if ( notNullSafeLong1 == notNullSafeLong2) {
      do suff

Esto requeriría implementar una anulación para == de modo que null == someLong sea falso y el caso especial Null == Null sea verdadero. En su lugar, tenemos que usar igual () y probar para nulo

    Long notNullSafeLong1 = new Long(11L)
    Long notNullSafeLong2 = new Long(22L)
    if ( (notNullSafeLong1 == null && notNullSafeLong2 == null) || 
      (notNullSafeLong1 != null && notNullSafeLong2 != null & 
        notNullSafeLong1.equals(notNullSafeLong2)) {
      do suff    

Esto es un poco más detallado que el primer ejemplo, si el autounboxing hubiera funcionado para el operador ''==''.

Answer 7

  public static Integer valueOf(int i) {
      final int offset = 128;
      if (i >= -128 && i <= 127) { // must cache
          return IntegerCache.cache[i + offset];
      }
       return new Integer(i);
    }

Por eso eres verdadero en un caso, y falso en otro!