Java es un lenguaje minimalista, deliberadamente con menos caracter\u00edsticas que otros lenguajes, nunca estas limitaciones tienen casos extremos con efectos extra\u00f1os, algunos casos con efectos sorprendentes hace tropezar a los incautos. Si has le\u00eddo otros lenguajes, puedes f\u00e1cilmente leer Java de la manera incorrecta llev\u00e1ndote a la confusi\u00f3n.<\/p>\n
<\/p>\n
Es correcto, las variables no son objetos<\/strong>. Esto significa que cuando ves lo siguiente:<\/p>\n [java] s<\/strong> no es un objeto, no es un String, es una referencia a un String<\/strong>.<\/p>\n Esto responde a muchas \u00e1reas de confusi\u00f3n como:<\/p>\n Para hacer mas grande la confusi\u00f3n, al usar == a veces funciona<\/strong>. Si se tiene dos valores inmutables que tienen el mismo contenido, la JVM puede intentar hacer la misma referencia. Ejm:<\/p>\n [java] En ambos casos, un pool de objetos es usado como referencia que al final termina apuntando al mismo lugar. s1 == s2 y a == b<\/em> ambos objetos devuelven true<\/em> porque la JVM<\/em> ha hecho referencia al mismo objeto<\/strong>. Ahora, al variar un poco el c\u00f3digo el pool de objetos no es el mismo y ==<\/strong> devolver\u00e1 false<\/strong> <\/em>quiz\u00e1s de forma inesperada. En este caso se necesita usar equals()<\/strong>.<\/p>\n [java] Para los Integer, el pool de objetos empieza en -128 hasta al menos 127<\/strong>(posiblemente mas)<\/p>\n Todas las variables son pasadas por valor, incluso las referencias<\/strong>. Esto significa que cuando se tiene una variable el cual es una referencia a un objeto, esta referencia es copiada, pero no el objeto. Ejm:<\/p>\n [java] El objeto de referencia puede ser cambiado, pero los cambios a la referencia no tienen efecto en el objeto que lo llama.<\/strong><\/p>\n Un hashCode()<\/em> tiene que permanecer constante<\/strong>. Sin esto de facto, los hash<\/em> de las colecciones como HashSet<\/em> o ConcurrentHashMap<\/em> no funcionar\u00edan. Sin embargo el objeto puede estar en cualquier lugar de la memoria y puede cambiar de lugar sin que el programa sepa que esto ha sucedido. Usar la posici\u00f3n para el hashcode()<\/em> no funcionar\u00eda (a menos que se tenga una JVM donde los objetos no se muevan).<\/p>\n Para el OpenJDK<\/em> y el HotSpot JVM<\/em> el hascode()<\/em> es generado bajo demanda y almacenado en la cabecera del objeto<\/strong>.<\/p>\n El comportamiento por default<\/em> de toString()<\/em> es imprimir el nombre interno de la clase y un hashCode()<\/em>. [java] La salida es algo como esto:<\/p>\n [java] Desafortunadamente se tiene que saber que la clase es un array de objetos<\/strong>, ejm. si se tiene un objeto words<\/em><\/strong>, se tiene un problema y se tiene que saber llamar a Arrays.toString(words<\/strong>)<\/em> en su lugar. Esta encapsulaci\u00f3n rota es una mala idea y una fuente com\u00fan de confusi\u00f3n en StackOverflow.<\/em><\/p>\n Traducido de: http:\/\/www.javacodegeeks.com\/2014\/03\/common-gotchas-in-java.html<\/a><\/p>\n\n
\nString s = "Hello";
\n[\/java]<\/p>\n\n
== compara sus referencias, no su contenido<\/h2>\n
\nString s1 = "Hi", s2 = "Hi";
\nInteger a = 12, b = 12;
\n[\/java]<\/p>\n
\nString s3 = new String(s1);
\nInteger c = -222, d = -222;
\n[\/java]
\n[java]
\ns1 == s2\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ is true
\ns1 == s3\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ is false
\ns1.equals(s3) \/\/ is true
\na == b\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ is true
\nc == d\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ is false (diferentes objetos fueron creados)
\nc.equals(d)\u00a0\u00a0 \/\/ is true
\n[\/java]<\/p>\nJava pasa referencias por valor<\/h2>\n
\npublic static void addAWord(StringBuilder sb) {
\n sb.append(" word");
\n sb = null;
\n}
\n[\/java]
\n[java]
\nStringBuilder sb = new StringBuilder("first ");
\naddWord(sb);
\naddWord(sb);
\nSystem.out.println(sb); \/\/ imprime "first word word"
\n[\/java]<\/p>\nEn la mayor\u00eda de las JVM’s<\/em>, el Object.hashCode()<\/em> no tiene nada que ver con la posici\u00f3n en memoria.<\/h2>\n
El Object.toString() hace algo sorprendentemente mas que \u00fatil.<\/h2>\n
\nComo se ha mencionado, el hashCode()<\/em> no es la ubicaci\u00f3n en memoria a pesar que se ha impreso un hexadecimal<\/strong>. Tambi\u00e9n para el nombre de la clase, especialmente con arrays es confuso. Por ejemplo un String[]<\/em> se imprimir\u00e1 como [Ljava.lang.String;<\/strong><\/em> El [<\/strong> siginifica que es un array, la L<\/strong> significa que es un clase creada por un \u00ablenguaje\u00bb, no una primitiva como un byte el cual por cierto tiene un c\u00f3digo de B<\/strong>; y el ;<\/strong> significa el final de la clase. Ejm:<\/p>\n
\nString[] words = { \u201cHello\u201d, \u201cWorld\u201d };
\nSystem.out.println(words);
\n[\/java]<\/p>\n
\n[Ljava.lang.String;@45ee12a7
\n[\/java]<\/p>\n