Problem in not overriding equals and Hashcode

> > ...we can not use the object in the Hashed

> collection....

>

> Why not? Where you got that?

Probably from the definition of hashCode and the way hashed collections work.

> maybe it's not that performant as with a good

> hashCode, but should work fine anyway.

No, it's not about bad performance. If you don't override equals and hashCode, and do so correctly, then your class will not work correctly in collections like HashMap and HashSet.

It is true that you can provide a correct but non-performant hashCode (e.g., return 42; is always correct but it will perform like krap), but that's not what the OP is asking about. He's asking about not overriding it in the first place.

jverda at 2007-7-12 18:10:14 >

> > No, it's not about bad performance. If you don't

> > override equals and hashCode, and do so correctly,

> > then your class will not work correctly in

> > collections like HashMap and HashSet.

>

> why not?

class Person {

String name;

}

Now let's say we want two people to be equal if they have the same name. We have to override equals. If we don't also override hashCode, then two equal objects will probably not hash to the same bucket and therefore will not be found.

> The only problem I can see is with the equals method.

> But if I consider different instances of my object to

> be diferent despite having the same internal values,

> there is no need to overwrite the equals method and

> consequently the hashCode method.

One doesn't usually do that for the kinds of things one puts into collections, however.

Also, override, not overwrite.

jverda at 2007-7-12 18:10:14 >

back to the original question from DebadattaMishra

> I have a very small question. We know that if we do

> not override the equals and hascode of Object class,

> we can not use the object in the Hashed collection.

> Can anybody provide me a concrete example which

> indicates the problem if we do not override the

> equals and hascode.

lets extend the example from jverd. Suppose we have a Person and want to store some Score in a HashMapclass Person {

String name;

Person(String name) {

this.name = name;

}

}

class Score {

int value;

Score(int value) {

this.value = value;

}

}

public class PersonTest {

Map<Person, Score> map = new HashMap<Person, Score>();

void test() {

map.put(new Person("John"), new Score(1));

map.put(new Person("Maria"), new Score(2));

//...

Score score = searchScore("John");

System.out.println("Found: " + score); // Found: null

}

Score searchScore(String name) {

return map.get(new Person(name));

}

}

if you run test() you will get "Found: null" since the John instance in the HashMap is not the same as used in searchScore. HashMap uses the equals method from Object since we have not overridden it.

If we add an equals methodclass Person {

String name;

Person(String name) {

this.name = name;

}

public boolean equals(Object obj) {

if(obj instanceof Person) {

Person p = (Person) obj;

return name.equals(p.name);

} else {

return false;

}

}

// hashcode not overridden

}

we probably will get "Found: null" most if the time. The HashMap uses the hashcode() to create an index for saving the keys, so it mostly will not find the Person.((there is still a very small probability that the correct Person is found))

It will work fine if we add a hashcode likepublic int hashCode() {

return name.hashCode();

}

I hope this example helped.

S_i_m_ua at 2007-7-12 18:10:14 >

> I got your point, but my problem was the sentence "we

> can not use the object in the Hashed

> collection..."

>

> sorry for my bad english, but it's neither my first

> nor second language...

I see.

Okay, yes, we *might* be able to use the object in a hash-based collection, but if we're not basing equality on any of the member variables, then it's fairly useless.

jverda at 2007-7-12 18:10:14 >