Jesper de Jong wrote:No, you did not implement the equals() and hashCode() methods correctly.
Ankush Seth wrote:Hello all, i am here to ask you weather i have implemented the contract correctly or not.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Ankush Seth wrote:Thank you Winston Gutkowski for your overwhelming response. I am glad to have opinion from you!!
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Javin Paul wrote:i.e. for same object equals() should return true and compareTo() must return zero.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Javin Paul wrote:Just to add, if you happen to implement Comparable also, make sure your compareTo() method is compatible with equals() i.e. for same object equals() should return true and compareTo() must return zero.
javadoc wrote: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.
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
I agree with you about that; I am sure there are people who would take the opposite view, however.Rob Spoor wrote: . . . 0.0 != 0.00, . . .
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Rob Spoor wrote:With BigDecimal I prefer the scientific approach - there is a reason for those extra zeros.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here