Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Couple of doubts in Comparator Interface

 
Parthiban Malayandi
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all ,
I'm studying Collections for SCJP .I have a doubt in Comparator interface .

While looking at the API I found that it contains two methods :

1.compare
2.equals

Here's where I'm stuck . while using Comparator mostly we are advised to (and most of the time only )override compare method but being a method in interface why we are not forced to override equals method ?

How it compiles successfully without overriding one method of interface ?

I also found it's because of equals method overrides from Object's class(if I understood correctly from API documentation )

what I understood is correct ?

It even confused me more .

How a interface extends a class(Object) ? (will it ?)
How a interface give implementation for a method ?

Please clarify my doubts .

Thanks in advance
 
Thomas Thevis
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Parthiban,

the equlas() method is only to compare different instances of Comparator implementations. For sorting data, it definetly suffices to implement the compare() mathod. I use the Comparator quite often and have never implemented equals() so far. So, why is it there and why don't we have to implement it? Well firstly, as you can see, the method signature is the same as the one from java.lang.Object. Since each class you implement inherits from Object, there is always a valid implementation matching the one from the Comparator interface. So, why is it there at all? If you read the API doc for Comparators equals() method carefully, you'll find that the interface specifies additional bahavior diverging from the Object's equals() specification. Therefore, the method is listed there. You don't have to implement equals(), but if you do, you have to fulfill the specification from the Comparator interface.

Hope this helps,
Thomas
 
Mohammad Khan
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Following code my help to understand the hidden issue here !


 
Thomas Thevis
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing I forgot to mention:
Although the Object's specification of equals() has been changed by the Comparator interface, the hashCode()'s specification has not. Therefore and as always, to not break the general contract of Object's hashCode(), you'll have to override hashCode() in case you decide to override equals().
 
Parthiban Malayandi
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Thomas Thevis:
Hey Parthiban,

the equlas() method is only to compare different instances of Comparator implementations. For sorting data, it definetly suffices to implement the compare() mathod. I use the Comparator quite often and have never implemented equals() so far. So, why is it there and why don't we have to implement it? Well firstly, as you can see, the method signature is the same as the one from java.lang.Object. Since each class you implement inherits from Object, there is always a valid implementation matching the one from the Comparator interface. So, why is it there at all? If you read the API doc for Comparators equals() method carefully, you'll find that the interface specifies additional bahavior diverging from the Object's equals() specification. Therefore, the method is listed there. You don't have to implement equals(), but if you do, you have to fulfill the specification from the Comparator interface.

Hope this helps,
Thomas


Hi Thomas and Mohammad,
Thanks for your replies now I understood why it worked and mentioned in API.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic