Menu
Back after a vacation :) with the questions. I am reading Comparable interface documentation from ComparableDocumentation. I do understand, that we use comparable as it will provide us with sorting and natural ordering. In the documentation, it is written as.
It is strongly recommended (though not required) that natural orderings be consistent with equals. This is so because sorted sets (and sorted maps) without explicit comparators behave "strangely" when they are used with elements (or keys) whose natural ordering is inconsistent with equals. In particular, such a sorted set (or sorted map) violates the general contract for set (or map), which is defined in terms of the equals method.
How does Comparable is related to equals. Comparable has compareTo method and why it needs to be consistent with the equals method? I am unable to understand this concept.
Also quoting from the sources, can someone elaborate on this point as well
For example, if one adds two keys a and b such that (!a.equals(b) && a.compareTo(b) == 0) to a sorted set that does not use an explicit comparator, the second add operation returns false (and the size of the sorted set does not increase) because a and b are equivalent from the sorted set's perspective.
Thanks.
602
2) CompareTo must be in consistent with equals method e.g. if two objects are equal via equals() , there compareTo() must return zero otherwise if those objects are stored in SortedSet or SortedMap they will not behave properly.
equals() is used to compare the two objects by some business logic and returns a boolean value. Use == operator when you want to compare the values of two primitive data types or you want to compare two references are same or not. Use . equals() method when you want to compare two objects by functionality.
The 2 main differences are that: equals will take any Object as a parameter, but compareTo will only take Strings. equals only tells you whether they're equal or not, but compareTo gives information on how the Strings compare lexicographically.
So by looking at the above problem, we can see that there is a hidden contract between equals and comparable. I termed this as "hidden contract" as If you do not maintain the contract no catastrophic failure will happen but when you use it with HasSet or TreeSet it can produce wired result.
The semantics of compareTo returning 0 is that the two objects are, well, equal. Having another definition of the same relation in the other method can obviously result in many kinds of trouble, as documented in your quote as well: the typical algorithms in SortedSet implementations rely on compareTo, but the general contract of the Set interface specifies that it must not contain two objects which are equals. The inconsistency of reports from compareTo and equals will result in just such a situation.
94
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
