quería probar el operador '==' s en Long
y esto es lo que he encontrado: el siguiente código:¿Cuál es la causa de este extraño comportamiento de Java?
public static void main(final String[] args) {
final Long n = 0L;
final Long m = 0L;
System.out.println(n + " == " + m + " : " + (n == m));
final Long a = 127L;
final Long b = 127L;
System.out.println(a + " == " + b + " : " + (a == b));
final Long A = 128L;
final Long B = 128L;
System.out.println(A + " == " + B + " : " + (A == B));
final Long x = -128L;
final Long y = -128L;
System.out.println(x + " == " + y + " : " + (x == y));
final Long X = -129L;
final Long Y = -129L;
System.out.println(X + " == " + Y + " : " + (X == Y));
}
salidas:
0 == 0 : true
127 == 127 : true
128 == 128 : false
-128 == -128 : true
-129 == -129 : false
La única explicación que podría venir fue que la JVM almacena todos los valores long
dentro de [-128, 127]
en el espacio Perm, y da su dirección a Long
sy a todo lo que está fuera del rango anterior crea una nueva asignación para cada valor estático encontrado en el código.
¿Estoy cerca de estar en lo cierto? ¿En qué situaciones debemos estar conscientes de comportamientos similares?
PS. Sé que debería usar un cheque null
y luego .equals()
para comparar objetos, pero tenía curiosidad si alguien sabía la respuesta.
EDITAR
Después jtahlborn 's respuesta que me dio la palabra clave de auto-boxing He encontrado este artículo con el well-documented answer
Sí, estás en lo correcto. (Y sí, usar '==' aquí en lugar de '.equals' es un pecado.) –
http://stackoverflow.com/questions/11955958/with-abstract-datatypes-different-results-for-the-same- kind-of-conditions/11955984 # 11955984 – kosa
NO debe usar una verificación nula. Los controles nulos son malvados. Simplemente no use NULL. –