thanks for your reply Campbell and Mike . you mean to say that equals() method from Comparator could have been eliminated but it is just a reminder that in this case we can override equals() and how should we override it. Please explain it a little bit more because i dont think that in java there are things that have no reason. Everything thing contains some special meaning.Thanks again.
sudhakarc kumar wrote:Please explain it a little bit more because i dont think that in java there are things that have no reason. Everything thing contains some special meaning.Thanks again.
The reason you've been given is the only reason. All interfaces automatically have a toString method included in them (JLS Section 6.4.4), so the only reason for explicitly including it in an interface is so that you can expand the Javadoc.
In common java objects, we will decide two objects are equal by checking its one or more than one instance variables.
Form javaDoc Comparator
return true -> only if the specified object is also a comparator and it imposes the same ordering as this comparator.
Means we need to check for its business logic (This is what really makes two comparators objects equal)
Also from JavaDoc
Note that it is always *safe not* to override Object.equals(Object).
Since the POJO class can have its own equals() which would check for some of its instance variables(Which makes it really unique). If we implement comparator interface in the same POJO class and provide the equals () for comparator then we cannot check equality for POJO class, vice versa. That is the reason it mentioned it's not to override equals().
As explained earlier this is to 'just to expand on the general contract of the method'. So that we would treat comparator equals() is different from POJO equals() .