Estoy un poco confundido acerca de la forma en que Java trata== yequals() cuando se trata deint, Integer y otros tipos de números. Por ejemplo:

Integer X = 9000;
int x = 9000;
Short Y = 9000;
short y = 9000;
List<Boolean> results = new ArrayList<Boolean>();
// results.add(X == Y); DOES NOT COMPILE        1)
results.add(Y == 9000);                      // 2)
results.add(X == y);                         // 3)
results.add(X.equals(x));                    // 4)
results.add(X.equals(Y));                    // 5)
results.add(X.equals(y));                    // 6)
System.out.println(results);

salidas (tal vez usted debe hacer su conjetura primero):

[true, true, true, false, false]

EseX == Y No compilar es de esperar, siendo objetos diferentes.Estoy un poco sorprendido de queY == 9 estrue, dado que 9 es por defecto unint, y dado que 1) ni siquiera compilaron. Tenga en cuenta que no se puede poner unaint en un método que espera unaShort, sin embargo, aquí son iguales.Esto es sorprendente por la misma razón que dos, pero parece peor.No sorprende, comox es autoboxed ayInteger.No es sorprendente, ya que los objetos de diferentes clases no deben serequal().¿¿Qué??X == y estrue peroX.equals(y) esfalse? No debería== siempre sea más estricto queequals()?

Apreciaría si alguien me puede ayudar a entender esto. ¿Por qué razón se comportan de esta manera == y equals ()?

Editar: He cambiado de 9 a 9000 para mostrar que este comportamiento no está relacionado con ninguna de las formas inusuales en que se comportan los enteros de -128 a 127.

2Dakota del Norte Editar: Bien, si crees que entiendes esto, debes considerar lo siguiente, solo para asegurarte:

Integer X = 9000;
Integer Z = 9000;
short y = 9000;
List<Boolean> results = new ArrayList<Boolean>();
results.add(X == Z);                      // 1)
results.add(X == y);                      // 2)
results.add(X.equals(Z));                 // 3)
results.add(X.equals(y));                 // 4)
System.out.println(results);

salidas:

[false, true, true, false]

La razón, por lo mejor que la entiendo:

Diferente ejemplo, tan diferente.X sin caja, entonces el mismo valor, tan igual.Mismo valor, tan igual.y no se puede encasillar a unInteger por lo que no puede ser igual.