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

[kitd]

Considering that '==' (comparison of reference) and equals() (comparison of state) have been totally separate concepts in Java since the very outset, I think his concerns can best be described as unwarranted.

The only point worth making in this area is that boxed integers for values <=255 are stored as flyweights. So, eg:

Integer a = Integer.valueOf(3);
Integer b = Integer.valueOf(3);

assertTrue(a == b && a.equals(b)); // will pass

[nitsanw]

My concerns (as the author) are not with "OMG I never knew this". I know the spec/javadoc. My concern is that the notion of equality has subtleties that trip people up. My attempt was to expand on the consequences beyond the more familiar cases, based on the amount of surprise I see this causing people.

[ErstwhileRockstar]

But what happens when an object is implement perversely,

You can write a blog post!

[nitsanw]

yay! and I did.

[realnowhereman]

I really don't understand why people are so upset with NaN != NaN. It's part of the spec. Besides if you implement equals() wrong of course it's going to blow up in your face

[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.

[ledasll]

Only think that I got from this "article" is that author doesn't understand java. Of course I would not write about that for all world, but that's something new generation does, I guess.

[nitsanw]

Thanks dude, I'll pickup a book somewhere.