overloading equals function
Hi all,
I am doing little "graph theory" in java - I have objectVertex as a vertex and objectEdge as an edge. Those familiar with graphs know, that edge is in fact a pair of vertices. So I overloaded equals function forEdge to check whether it contains the same pair ofVertex objects.
It is working as far as cosideringEdge.equals(Edge .). But when I am puttingEdges into the set (I am usingHashSet), it is possible to put there moreEdges with the same pair ofVertex objects. It looks that the set is considering them as different.
IsHashSet using some other mean than "equals" to check for equality of objects? Or is somehow using theObject.equals(Object.)? Or is something wrong with my approach?
Thanks
[839 byte] By [
Skoreca] at [2007-10-2 21:20:02]
for hash set, I believe two items are considered to be equal if and only if item1.equals(item2) and item1.hashCode() == item2.hashCode().i.e., you need to override hashcode to make them both equal as well.- Adam
btw, this isn't technically overloading (at least, I hope you're not actually overloading the equals method, because that won't help you). It's overriding. there is a small diference between overloading and overriding, but it makes a big difference in the way your program runs.
- Adam
You are right - the problem was that I was overloading the equals function instead of overriding it
moreover - to force the HashSet to consider them as equal I need to override HashCode. This is strange because in documentation on Object.hashCode() at Sun`s page is :
"If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result."
Does it mean that overriding equals(Object) without overriding hashCode() will produce some inconsistency and possible problems?
btw. thanks for help
It's the way HashSmth classes work, they are dependant on hashcode and to optimize perfomance first copare hashcodes (i.e. int value) and only if hashcodes equal go to compare complex object with equal method.
> Does it mean that overriding equals(Object) without
> overriding hashCode() will produce some inconsistency
> and possible problems?
Yes.
In particular, in hash-based data structures such as HashMap and HashSet, when you go to search for an entry (Set) or key (Map) that's equal to another one, if you didn't override hashCode, you probably will not find the equal one that's already there, because first it uses hashCode to narrow down the potential matches.
> Does it mean that overriding equals(Object) without
> overriding hashCode() will produce some inconsistency
> and possible problems?
not necessarily, in most cases. I would say that nine times out of ten, the equals method alone will be enough to determine if objects are equal.
however, because it is part of the equals contract that two equal objects must return the same hash code, some programmers may choose to depend on this. so it is generally a good idea to ensure that you override both of them.
one BIG place where this is important is the Collections framework, which highly depends on the hash code of objects.
if you're new to overriding equals and hashCode, I highly recommend reading chapter 3 of Joshua Bloch's Effective Java. That chapter is posted as a sample on sun's website:
http://java.sun.com/developer/Books/effectivejava/Chapter3.pdf
- Adam
> > Does it mean that overriding equals(Object)
> without
> > overriding hashCode() will produce some
> inconsistency
> > and possible problems?
>
> not necessarily, in most cases. I would say that
> nine times out of ten, the equals method alone will
> be enough to determine if objects are equal.
If you know your object will never be used in a hash-based data structure, then it can be okay to not override hashCode when do equals. But I can't think of any good reason to do it that way. It only takes a couple of minutes to do it, and then you know your class is solid in that respect.
