Always adhere strictly to the contract of an interface you implement, especially one such as Comparable
that's defined in the core API. If you can't define a total order on your type such that the comparison of two objects is always stable and that transitive comparison is always stable, your class will cause runtime failures in code that can be far removed from your class, especially if your objects are added to a Set
.
Your use case really doesn't sound like you're describing an ordering of the elements, but rather some kind of equals
; Comparable
/Comparator
seems to be the wrong approach entirely.