jQuery in Action, 3rd edition
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes confusion about comparator, comparable and hashcode Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "confusion about comparator, comparable and hashcode" Watch "confusion about comparator, comparable and hashcode" New topic
Author

confusion about comparator, comparable and hashcode

Fritz Guerilus
Ranch Hand

Joined: Jun 20, 2009
Posts: 65
Hi,
Can anyone clear this up for me:

The point of using the comparator & comparable interface is to sort objects in collections. Right?

Don't the hashcode/equals methods play a role in sorting in generic collections?

Do you still need to override the hashcode/equals method for the class which implements the comparator/comparable interfaces?

Sometimes I see classes which implement these interfaces, override the appropriate compareTo/compare methods.
Then I see the those classes which implement these interfaces put in as generic types for collections such as TreeSet.
But I don't see where it indicates overriding the hashcode and equals methods.

Thank You


SCJP 6.0
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9405
    
  20

Equals and hashCode cannot play a role in sorting. This is because they don't tell in any way whether an object is greater or smaller than the other. If you are using a comparable object in a TreeSet or TreeMap, then you don't need to override the equals or hashCode method. The TreeSet and TreeMap uses the compareTo/compare method to check equality (i.e. if compareTo/compare method returns 0, then objects are considered equal)...


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Salil Vverma
Ranch Hand

Joined: Sep 06, 2009
Posts: 255

Hey Fritz ,
The point of using the comparator & comparable interface is to sort objects in collections. Right?
This is correct.
Don't the hashcode/equals methods play a role in sorting in generic collections
nope, hash code and equals play role in searching not in sorting. As you can see in the below code, equals and hash code has not been overridden still is sorts the ArrayList well.




Do you still need to override the hashcode/equals method for the class which implements the comparator/comparable interfaces?

- You need not to implement hascode and equals if you only want to do sorting not seraching (by verifying logical equal comparision). As you can see the above code it does not find the position of "First name" in the collection because we have not overridden equals method.



Sometimes I see classes which implement these interfaces, override the appropriate compareTo/compare methods.
Then I see the those classes which implement these interfaces put in as generic types for collections such as TreeSet.
But I don't see where it indicates overriding the hashcode and equals methods.


For any collection to be in tree set, it must implement comparable interface so that TreeSet could maintiain its property by keeping the elements in sorted order. It does not matter whether equals and hash code has been implemented or not. (As mentioned in the above code)

I hope this would be help full.

Regards
Salil Verma

Regards
Salil Verma
Anushree Acharjee
Greenhorn

Joined: Aug 01, 2012
Posts: 2
Thanks Salil for the great explanation. But the following code makes me wonder whats happening

Roel De Nijs
Sheriff

Joined: Jul 19, 2004
Posts: 7251
    
  29

Anushree Acharjee wrote:But the following code makes me wonder whats happening

A TreeSet IS-A SortedSet. This section from the SortedSet javadoc will explain what's happening:
SortedSet wrote:Note that the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface. (See the Comparable interface or Comparator interface for a precise definition of consistent with equals.) This is so because the Set interface is defined in terms of the equals operation, but a sorted set performs all element comparisons using its compareTo (or compare) method, so two elements that are deemed equal by this method are, from the standpoint of the sorted set, equal. The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.

The same applies to a TreeMap (which is a SortedMap).

Hope it helpds!
Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
OCAJP 7
Anushree Acharjee
Greenhorn

Joined: Aug 01, 2012
Posts: 2
Thanks Roel.

So it means,contrary to as Salil explained, we need not to override equals() an hashCode() methods even when we are searching TreeSet or TreeMap. For sorting we need compareTo/compare method implementation. equals() and hashCode() do not come into the picture at all when dealing with TreeSet and TreeMap.

Roel De Nijs
Sheriff

Joined: Jul 19, 2004
Posts: 7251
    
  29

Anushree Acharjee wrote:So it means,contrary to as Salil explained, we need not to override equals() an hashCode() methods even when we are searching TreeSet or TreeMap. For sorting we need compareTo/compare method implementation. equals() and hashCode() do not come into the picture at all when dealing with TreeSet and TreeMap.

If you want to sort, you can't do anything with the equals method. Why? For the very simple reason: the return type of the equals method is boolean, so you can only return true (both objects equal) or false (both objects not equal). So you can only determine if 2 objects are equal, not if one object is greater than the other one. It's just like with 2 int values: if you only could use the equality operator (==), you could only know if 2 int values are equal, but not which is the smallest/greatest value.

If you add items to a Set (a collection of unique elements), you need to implement equals and hashCode methods. Otherwise you will have duplicate elements in your set (which sould only contain unique elements). A TreeSet doesn't use the equals/hashCode method, but the compareTo-method (or compare-method). Because this method defines sorting, it's also capable of telling when 2 objects are equal (when compareTo returns 0).
So there's a very important implication as you don't know to which kind of collections your elements will be added (HashSet, LinkedHashSet, TreeSet): to be consistent with the Set interface, the implementation of the equals-method and compareTo-method must be consistent with each other. Otherwise you'll get a different outcome if you add the same items to a HashSet and a TreeSet. Therefore you could implement the compareTo-method as you like and implement the equals method like:With this code you are guaranteed equals and compareTo will return consistent values. And if you add your items to an ArrayList, you'll only get correct return values from methods like contains and indexOf if you implemented the equals method correctly.

Hope it helps!
Kind regards,
Roel
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: confusion about comparator, comparable and hashcode
 
It's not a secret anymore!