convert - string to int javascript
Java: El entero es igual a== (5)
"==" siempre compara la ubicación de la memoria o las referencias a objetos de los valores. El método igual siempre compara los valores. Pero equals también usa indirectamente el operador "==" para comparar los valores.
Entero usa la memoria caché Integer para almacenar los valores de -128 a +127. Si el operador == se usa para verificar cualquier valor entre -128 a 127, entonces devuelve verdadero. para otros que estos valores, devuelve falso.
Consulte el link para obtener información adicional
A partir de Java 1.5, puedes intercambiar Integer con int en muchas situaciones.
Sin embargo, encontré un defecto potencial en mi código que me sorprendió un poco.
El siguiente código:
Integer cdiCt = ...;
Integer cdsCt = ...;
...
if (cdiCt != null && cdsCt != null && cdiCt != cdsCt)
mismatch = true;
parecía estar configurando incorrectamente el desajuste cuando los valores eran iguales, aunque no puedo determinar en qué circunstancias. Establecí un punto de interrupción en Eclipse y vi que los valores Integer eran 137, inspeccioné la expresión booleana y dijo que era falsa, pero cuando puse el pie sobre ella, estaba configurando la discrepancia como verdadera.
Cambiar el condicional a:
if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt))
arregló el problema
¿Alguien puede arrojar algo de luz sobre por qué sucedió esto? Hasta ahora, solo he visto el comportamiento en mi localhost en mi propia PC. En este caso particular, el código logró superar las 20 comparaciones, pero falló en 2. El problema fue consistentemente reproducible.
Si es un problema frecuente, debería estar causando errores en nuestros otros entornos (desarrollo y prueba), pero hasta ahora, nadie ha informado del problema después de cientos de pruebas que ejecutan este fragmento de código.
¿Todavía no es legítimo usar == para comparar dos valores Integer ?
Además de todas las buenas respuestas a continuación, el siguiente enlace 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é no puede el compilador / JVM simplemente hacer que el autoboxing "simplemente funcione"?
El problema es que tus dos objetos Integer son solo eso, objetos. No coinciden porque está comparando sus dos referencias de objeto, no los valores dentro. Obviamente .equals se reemplaza para proporcionar una comparación de valores a diferencia de una comparación de referencia de objeto.
La JVM está almacenando en caché valores enteros. == solo funciona para números entre -128 y 127 http://www.owasp.org/index.php/Java_gotchas#Immutable_Objects_.2F_Wrapper_Class_Caching
No puede comparar dos Integer con un simple == son objetos, por lo que la mayoría de las referencias de tiempo no serán las mismas.
Hay un truco, con Integer entre -128 y 127, las referencias serán las mismas que cuando Autoboxing usa Integer.valueOf() que almacena en caché números enteros pequeños.
Si el valor p que está siendo encasillado es verdadero, falso, un byte, un carácter entre el rango / u0000 a / u007f, o un número entero o corto entre -128 y 127, entonces r1 y r2 serán los resultados de dos conversiones de boxeo de p. Siempre es el caso que r1 == r2.
Recursos:
Sobre el mismo tema:
Integer refiere a la referencia, es decir, al comparar las referencias que está comparando, si apuntan al mismo objeto, no al valor. Por lo tanto, el problema que estás viendo. La razón por la que funciona tan bien con tipos enteros simples es que desagrupa el valor contenido por el Integer .
Puedo agregar que si estás haciendo lo que estás haciendo, ¿para qué empezar con la declaración if ?
mismatch = ( cdiCt != null && cdsCt != null && !cdiCt.equals( cdsCt ) );