0

I am using adding an object to a TreeSet. And I never use that in any Hash-based collection. I feel that the TreeSet need overriding of compareTo method equals method overriding is not required. Is it a good practice not to override equals method? If No then why equals method override is required as I will not be using it in Hash-based collection?

Update: javadoc says,

It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

Honestly I did not understand the cause behind that strong recommendation of equals implementation.

poddroid
  • 845
  • 1
  • 14
  • 26
  • Depends on the class - http://stackoverflow.com/questions/11010626/when-should-i-override-equals-function – wkl Aug 26 '13 at 16:15

4 Answers4

4

It's best practice to always keep hashCode()and equals() aligned.

You don't know that next week you might use it in a HashMap, and someone else using your class will assume its been done too.

yshavit
  • 42,327
  • 7
  • 87
  • 124
Bohemian
  • 412,405
  • 93
  • 575
  • 722
  • 1
    +1, because a bit of effort today is well worth it if it reduces head-scratchers a year from today. Especially in cases like this, where the "right thing" will take about 5 seconds. – yshavit Aug 26 '13 at 16:22
2

why equals method override is required as I will not be using it in Hash-based collection?

The equals method is required to avoid surprises. You say you will not be using it in a hash-based collection; but someone else might. I would even go so far as to say that you yourself might change from TreeSet to HashSet without remembering you need to add equals.

This is just one reason, one instance why you should implement equals to be consistent with compareTo. You can think of others but essentially they all refer to consistency -- it is intuitive that if x.compareTo(y) == 0 then x.equals(y).

Miserable Variable
  • 28,432
  • 15
  • 72
  • 133
0

Overriding equals() has nothing to do with hash containers. It has to do with whether you want a custom notion of equality for the class. If you override compareTo(), then you do, so for simple correctness, you should override equals().

Overriding hashCode() has very little to do with hash containers either. It just happens to be used by them, but other things could use hash codes too. You should always keep hashCode() in sync with equals(); there's no excuse not to do it.

The strong recommendation is there to minimize surprises. If compareTo() returns 0, then I expect the two objects to be equal - it would be extremely confusing if equals() disagreed.

Sebastian Redl
  • 69,373
  • 8
  • 123
  • 157
  • Frankly, I see no reason for "equals" to even exist. Why can't equals just always be "return this.compareTo(arg)==0"? – Cruncher Aug 26 '13 at 16:30
  • Because not all types *have* `compareTo`. A natural total ordering (which is what `Comparable.compareTo` should represent) is far less common than a natural equality. E.g. complex numbers don't have a natural ordering, but it does have equality. – Sebastian Redl Aug 26 '13 at 16:32
  • But complex numbers are countable :) though I guess you couldn't call that a natural ordering – Cruncher Aug 28 '13 at 11:22
  • Default ordering != natural ordering. ;) – Sebastian Redl Aug 28 '13 at 12:39
-1

It is always good or rather necessary to compare your java objects using equals instead of == operator. Because in equals implementation, you can compare the objects against their attributes values. Whereas using ==, you can only check whether two reference are pointing to the same memory object or not.

In case of hashed collection it becomes more important because of the complexity of retrieval of objects.

Juned Ahsan
  • 67,789
  • 12
  • 98
  • 136