3 ms·
From the javadoc: > It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y)). Generally speaking, any class that impleme
by gizmo686 2y ago
From the javadoc:
> 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."
- auggierose 2y agoNice catch. Now you also found buggy documentation / specification!
- xboxnolifes 2y agoWhy is it buggy?
- auggierose 2y agoWhy would you allow .equals and .compareTo to have inconsistent meanings? That is a guaranteed source of bugs. I cannot think of a single good reason to allow this. If you need a different order for some reason, that is what the Comparator interface is for.
- maxbond 2y agoIf it's a bad idea but considered legal according to the documentation, then that would make it a footgun rather than a bug, no?
- auggierose 2y agoYes, that makes this a footgun, and the specification containing this footgun buggy. It is a bug in the spec because there is no good reason for the footgun being there.
- maxbond 2y agoYou have not yet imagined a reason, and neither have I. That doesn't mean one doesn't exist. Likely it would be something idiosyncratic involving legacy code that would only make sense in a real world context - "we have to change the way it sorts to fix ticket ABC123, but we can't change the equality, or we'll have a regression of ABC456."
- auggierose 2y agoThen provide a comparator to sort differently, no problem. There will never be a good reason for the spec to be like that. Just look how people here justify the mess of BigDecimal.
- myrryr 2y agoThings where equality is on more than one axis, _but there is a primary one where people use._ Think things like vectors or complex numbers, or people. The absolutely classic example however is types which have a signed zero...
- auggierose 2y agoThat is not a problem, just pick the same equality that your .compareTo method uses. You could pick -0 < 0, and -0 ≠ 0, or -0 = 0. You should never pick -0 < 0 (via compareTo), but -0 = 0 (via equals).
- tsimionescu 2y agoIt is perfectly reasonable to want all sorted collections of X to have a canonical order, but to still allow people to consider equivalent items to be equal. The example someone else gives with +0 and -0 is very good: in most contexts, those two should probably be equal (+0.equals(-0)), but when sorting a list, you might want all -0s to come before all +0s (-0.compareTo(+0) == -1). Given that Comparable is almost exclusively used for sorting, this is actually quite unlikely to cause problems in practice. Of course, it's a much bigger problem if you use entirely different concepts of equality. For example, a Name class where a.equals(b) only if they have the exact same Unicode code points, but where a.compareTo(b) == 0 if they have the same Unicode codepoints after normalization would be crazy. Edit: and of course BigDecimal from the example below does exactly this crazy thing...
- auggierose 2y agoYep, BigDecimal does this crazy thing, and it shouldn't. It does it, because the buggy spec allows it. If the canonical equality you want to provide is not compatible with the canonical order you want to provide, then don't provide the canonical order. Or provide an order that is compatible, which makes it pretty much canonical. It is really simple, and going against simple things like that is why software is such a mess. Because software really allows you to do anything you want. And now it is down to you to want the right thing.