.equals() and .compareTo(_) == 0 are required to be the same. If you program it differently, it is a bug.
> 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."
There will never be a good reason for the spec to be like that. Just look how people here justify the mess of BigDecimal.
Think things like vectors or complex numbers, or people.
The absolutely classic example however is types which have a signed zero...
You could pick -0 < 0, and -0 ≠ 0, or -0 = 0. You should never pick -0 < 0 (via compareTo), but -0 = 0 (via equals).
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...
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.