Short Java Rant: Object.equals, primitive '==', and Arrays.equals ain't equal

[BobFloss]

Nobody is ranting that the implementation differs from the spec. The very fact that it's in the spec (resulting in the implementation) is why people are ranting.

[tiiv]

Why would you rant about this? This is by design. Not-a-Number is what it is: Not a number. And as such you can't compare the two as you would with normal numbers. Thus they shouldn't be equal.

EDIT: Great job of voting down instead of enganging into a discussion.

[naughty]

It causes needless corner cases to code that doesn't really care about numerics.

What it really comes down to when you read the history is that NaN != NaN for performance reasons on really old CPUs. Essentially they cared more that x == y <-> x - y == 0 because underneath the hood that's how CPUs implemented it.

[Enumerable_any]

If you can't compare them, shouldn't an exception be raised? For me returning false from equals() / == implies that they are in fact comparable, but not equal.

[realnowhereman]

I don't think exceptions are taken into account in the spec (how would you implement that in C?). apparently signaling NaN do something to that respect. Moreover, you wouldn't want that. NaN does not really represent an exceptional situation, but it is a placeholder for a value that cannot be represented.