A partir de Java 1.5, puedes intercambiar prácticamenteInteger conint en muchas situaciones

Sin embargo, encontré un posible defecto en mi código que me sorprendió un poco.

El siguiente código:

Integer cdiCt = ...;
Integer cdsCt = ...;
...
if (cdiCt != null &a,mp;& cdsCt != null && cdiCt != cdsCt)
    mismatch = true;

parecía estar configurando incorrectamente la falta de coincidencia cuando los valores eran iguales, aunque no puedo determinar en qué circunstancias. Establecí un punto de interrupción en Eclipse y vi que elInteger ambos valores eran 137, e inspeccioné la expresión booleana y dijo que era falsa, pero cuando la detuve, estaba configurando la falta de coincidencia en verdadero.

Cambiar el condicional a:

if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt))

Arreglado el problema.

¿Alguien puede arrojar algo de luz sobre por qué sucedió esto? Hasta ahora, solo he visto el comportamiento en mi host local en mi propia PC. En este caso particular, el código superó con éxito unas 20 comparaciones, pero falló en 2. El problema fue reproducible de manera consistente.

Si es un problema frecuente, debería estar causando errores en nuestros otros entornos (desarrollo y prueba), pero hasta ahora, nadie ha informado el problema después de cientos de pruebas que ejecutan este fragmento de código.

¿Todavía no es legítimo usar== para comparar dosInteger ¿valores?

Además de todas las buenas respuestas a continuación, el siguiente enlace de stackoverflow tiene bastante información adicional. En realidad, habría respondido a mi pregunta original, pero como no mencioné el autoboxing en mi pregunta, no apareció en las sugerencias seleccionadas:

¿Por qué el compilador / JVM no puede hacer que el autoboxing "simplemente funcione"?