Reto Java - Para probar un poco los conocimientos

Iniciado por ~ Yoya ~, Julio 26, 2013, 01:38:20 AM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

Dado el codigo de abajo, explicar porque retorna true o false, en cada caso.

Código: java
public class xD {
    public static void main(String[] args) {

        Integer a1 = 600;
        Integer a2 = 600;

        Integer b1 = 100;
        Integer b2 = 100;

        String a = "hola";

        StringBuilder strB = new StringBuilder("hola");

        System.out.println(new Integer(5) == new Integer(5)); // false
        System.out.println(a1 == a2);// false
        System.out.println(b1 == b2); //true
        System.out.println(a.equals("hola")); //true
        System.out.println(strB.equals("hola")); // false

    }
}


Salida:

Citarfalse
false
true
true
false

Saludos.
Mi madre me dijo que estoy destinado a ser pobre toda la vida.
Engineering is the art of balancing the benefits and drawbacks of any approach.

Pues vamos alla:

1) estas haciendo new y comparando las referencias de los objetos, por lo tanto da false porque son diferentes objetos
2) Aqui pasa igual, porque integer es un tipo objeto y se hace una conversion, y si no usas ecual comparas referencias
3) Aqui pasa como el anterior, pero segun el debunger. se le a asignado el mismo objeto (Ni idea de porque aqui pasa esto)
4) al usar equal estas comparando el contenido de los objetos y por lo tanto da el valor true deseado
5) Aqui da false porque stringBuilder no sobrescribe el metodo equal y por lo tanto se llama al que se ereda de object que devuelve siempre false

Saludos

1 - Comparas dos objetos, no los valores de ambos. Esto son dos "hashes" distintos (no confundir con direcciones de memoria).
2 - Exactamente lo mismo que lo anterior, la unica diferencia es que no lo estamos creando en el mismo momento, estos dos objetos se crearon antes.
3 - Se hace exactamente lo mismo, en este caso devuelve true. Depende de la implementación de la maquina virtual, supongo que la jvm parece estar usando el mismo objeto para ciertos valores coincidentes, luego no tiene por que ser así. Desconozco el criterio exacto por el cual puede dar true o no, pero si declaras Integer a1 = 1; e Integer a2 = 1; parece lógico que la jvm cree dos referencias y un solo objeto para "optimizar" un poco ya que se almacena el mismo valor. Esto no quiere decir que siempre vaya a ser así.
4 - La implementación de String.equals() compara el valor contenido por el objeto string con el literal o con el objeto que le pases como argumento. El valor evidentemente da true.
5 - StringBuilder usa el método equals() de la clase object. Esto es, objeto1 == objeto2 <==> objeto1.equals(objeto2) para las instancias de la clase Object y de todas aquellas clases que no sobreescriban el método equals() de la clase Object.

Gracias por la participación chicos, por lo comentarios, veo que tanto Arkangel, como 16BITBoy, tienen buen conocimiento de java. La respuesta incorrectas, no la responderé ahora por si alguien llega a responderla.



@Arkangel,

1 - Exacto
2 -  Falso, recuerda que cuando se utilizas Wrapper para comparar utilizando el operador relacional ==, estos se convierte en sus datos primitivos para realizar la comparación, pero hay algunas excepciones, hay es donde esta la clave. Por otro lado haz acertado que se debe utilizar equal para verificar la igualdad y es lo recomendado, pero no es la respuesta a la pregunta.
3 - Como no estas seguro, te digo que al unico objeto que se le asigna la misma direccion de referencia cuando se declara, es al objeto String siempre y cuando el valor que le hayas dado sea literal y no sea directamente instanciando el objeto String y pasandole el valor al constructor.
3 - Correcto, La clase String sobre-escribe el método equal y también el método hashCode. Recordando que para que un objeto sea considerado igual a otro, este debe también tener el mismo hashCode.
4 - Correcto, StringBuilder no sobre-escribe el método equal, y tampoco el método hashCode.

Buenas respuesta @Arkangel, ya que también haz utilizado los términos correcto y eso significa que conoces bien el lenguaje y no solo su sintaxis.



@16BITBoy,

1 - Correcto, ya que son distintos hashes, en la comparación el resultado es falso. Pero en realdad estas comparando los valores de los objectos y esos valores son la referencia de los objetos.
2 - Falso, en este caso hay algo diferente, una excepción en el comportamiento de la JVM.
3 - Como no conoces el criterio exacto, mejor obviamos la respuesta por si luego quieres responderla.
4 - Correcto compañero
5 - Correcto, no hay nada que agregar solo que tampoco sobre-escribe el metodo hashCode.

Buena participación @16BITBoy, me gusto mucho tu ultima respuesta, ya que describiste como funcionaba internamente el comportamiento, ese tipo de respuesta son la que me gusta ya que muchos saben codear pero no todos conocen verdaderamente el lenguaje que utilizan.



Saludos chicos.
Mi madre me dijo que estoy destinado a ser pobre toda la vida.
Engineering is the art of balancing the benefits and drawbacks of any approach.

pues yo considero que en java para tipos no primitivos hacer esto:
Código: java

Integer a1 = 600;

es lo mismo que hacer
Código: java

Integer a1 = new Integer(600);

Porque cuando usas dato no primitivo, se crea un objeto para este y por lo tanto es como hacer un new. y como esto los convierte en punteros a objetos. el == es exactamente lo mismo en los dos casos. una comparación para ver si es el mismo objeto

Saludos

Por lo visto como nadie ha constetado correctamente la 2º y la 3º pregunta, la contesto.

2 - El resultado es falso, ya que cuando se declara un Integer y se le asigna un valor literal (sin hacer una instanciacion) y se compara  utilizando el operador relacional (==) con otro Integer con el mismo valor (declarado literalmente), dara verdadero siempre y cuando el valor no pase de 127. En este caso el valor sobre-pasa los 127, por tal razón el resultado es falso.

3 - Verdadero, basado en la información de la respuesta 2.
Mi madre me dijo que estoy destinado a ser pobre toda la vida.
Engineering is the art of balancing the benefits and drawbacks of any approach.