Without overridding equals & hashCode ;how it is allowing to search in Map?? : Map Program

[Prashant Mumbarkar]

I am trying run below code

package SCJP;
import java.util.*;
/**
 *
 * @author Prashant
 */
class Don{
    public Don(String n)
    {
        name=n;
    }
    
    public String name;
    public boolean euqals(Object o)
    {
        return(o instanceof Don) && (name==((Don)o).name);
    }
    public int hashCode()
    {
        return name.length();
    }
    public String toString()
    {
        return "My name is "+ name;
    }
}

class Man{}

public class MapSet {
    public static void main(String[] args)
    {
        Map<Object,Object> m= new HashMap<Object,Object>();
         m.put(new Don("Sam"),"D1");
        Don k= new Don("Roy");
        m.put(k,"D2");
        m.put(new Man(),"M1");
        Man q= new Man();
        m.put(q,"M2");
        
        System.out.println(m.get(new Don("Sam")));
        System.out.println(m.get(k));
        System.out.println(m.get(new Man()));
        System.out.println(m.get(q));
        
       
        
    }
    
    
}

I was expecting output like D1 D2 null null (of course in different lines) as Man has not overrode equal & hashCode method

but output is like null D2 null M2 . Now I have no clue about this. Any idea how this works?

[Jesper de Jong]

Maybe it is because you made a typo in the name of the "equals" method.

public boolean euqals(Object o) 

Hint: Use the @Override annotation to help you detect such errors.

// The compiler will complain because the "euqals" methods is not overriding any method from a superclass
@Override
public boolean euqals(Object o)

If you don't override equals() and hashCode(), then the equals() and hashCode() methods of class Object will be used. The equals() method of class Object returns the same as what == would return, in other words, the result is true only if you compare an object with itself. And the hashCode() method is implemented so that the contract that's necessary is fulfilled (equal objects must have the same hash code).

[Prashant Mumbarkar]

Oops ...Apology for typo..

now output is D1 D2 null M2

but last one it should produce null rite? ( As Man has not overrode equals & hashCode methods)

[Matthew Brown]

The last one you are looking up with exactly the same key as it was added - the same object. So even the non-overridden versions of equals() will return true and hashCode() will return the same value.

[Prashant Mumbarkar]

Matthew Brown wrote:The last one you are looking up with exactly the same key as it was added - the same object. So even the non-overridden versions of equals() will return true and hashCode() will return the same value.

Thanks Matthew.
Now I have this doubt.

I used display statement in equals to see if this code is executed or not.

@Override
    public boolean equals(Object o)
    {
        System.out.println("I am in equal " + name);
        return(o instanceof Don) && (name==((Don)o).name);
    }

now in the same code earlier I made change like this

Don k= new Don("Roy5");
        m.put(k,"D2");




k.name="Dean";
        System.out.println(m.get(k));

Output is like this:

I am in hash Dean
D2

My question is why didn't it execute equal method? .Had it been executed ,then the output would have been null not D1 because Dean !=Roy5. Any thought on this please?

[Campbell Ritchie]

You are probably using the == operator incorrectly in that equals method, so it will behave incorrectly.
You have missed out the common first part of the equals method

@Override public boolean equals(Object ob)
{
   return ob == this ||
   ...
}

The equality test in the Map compensates with something like

if (ob1 == ob2 || ob1 != null && ob1.equals(ob2)) ...

Now you are passing the same object, so the first half of the test returns true and the second part is never executed. You are overriding the equals method incorrectly; it is designed to return a boolean, not to print out a message. There is no guarantee anywhere that any messages will be printed, so using the equals method to print messages is unpredictable and the behaviour of that message is undefined.
Remove the print statement and believe that whoever wrote HashMap knows what they are doing.

[edit]Found error: changed | to || [/edit]

[Prashant Mumbarkar]

Thanks Campbell for your comment

 @Override
    public boolean equals(Object o)
    {
        System.out.println("I am in equal " + name);
        if((o instanceof Don)&& ((Don)o).name==name)
            return true;
        else
            return false;
    }

now I have this correct version of equals method.

I agree that earlier equals method was not correct but I beg to differ you on unpredictability of display statements in it. My view is if it's method then no matter what it returns we can include display statements to see how actual flow is happening.

Now coming back to question I have for below code

m.put(new Don("Sam"),"D1");
        Don k= new Don("King");
        m.put(k,"D2");


System.out.println(m.get(new Don("Sam")));
       k.name="Dean";
        System.out.println(m.get(k));

Now output is

I am in hashSam
I am in equal Sam
D1
I am in hashDean
D2

Hence my question remains open : why is it not using equals method in second case & if it had then the output of search would have been null,rite?

[Jesper de Jong]

Remember the rule that hashCode() and equals() have to follow:

If two objects A and B are equal (calling A.equals(B) and B.equals(A) returns true), then their hash codes must be the same (A.hashCode() == B.hashCode()).

(If the equals() and hashCode() methods of the class of A and B don't follow that rule, then they are implemented incorrectly).

Note that the rule only works one way: it does not mean that if A and B are not equal, their hash codes must be different - they can still be the same.

Now, think about what it means. It means that if you have two objects A and B, and you compare their hash codes, and you find that their hash codes are different, then you can be sure that A and B are not equal. (Because if they are equal, their hash codes must be the same). So, HashMap doesn't always have to call equals() to know that two objects are different - when it sees that the hash codes are different, it already knows the objects are different, and it doesn't need to call equals().

[Prashant Mumbarkar]

Jesper de Jong wrote:Remember the rule that hashCode() and equals() have to follow:

If two objects A and B are equal (calling A.equals(B) and B.equals(A) returns true), then their hash codes must be the same (A.hashCode() == B.hashCode()).

(If the equals() and hashCode() methods of the class of A and B don't follow that rule, then they are implemented incorrectly).

Note that the rule only works one way: it does not mean that if A and B are not equal, their hash codes must be different - they can still be the same.

Now, think about what it means. It means that if you have two objects A and B, and you compare their hash codes, and you find that their hash codes are different, then you can be sure that A and B are not equal. (Because if they are equal, their hash codes must be the same). So, HashMap doesn't always have to call equals() to know that two objects are different - when it sees that the hash codes are different, it already knows the objects are different, and it doesn't need to call equals().

I completely agree with you...

@Override
    public boolean equals(Object o)
    {
        System.out.println("I am in equal " + name);
        if((o instanceof Don)&& ((Don)o).name==name)
            return true;
        else
            return false;
    }
    @Override
    public int hashCode()
    {
        System.out.println("I am in hash" + name);
        return name.length();
    }

Then as per that logic if A & B are having same hascodes then it should check for their equals method to see if they are matching or not. And this is what I expect in second case of my problem .But in result if you see it has stopped at hashcodes even though hashcodes are same ( King and Dean are of same length) .I think as per rule it should have gone to equals to do the check further & then it should have come with output null as (King!=Dean).

[Campbell Ritchie]

Prashant Mumbarkar wrote: . . .

now I have this correct version of equals method.

. . .

No, you haven't. As long as you are using == on reference types that is incorrect.

I found a mistake in my earlier post and had to change | to ||