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!