Am 2015-11-23 um 16:05 schrieb Attila Szegedi:
+1. As you correctly point out, this was caused by JDK-8043608. Strangely
enough, I fixed the NaN case for strictEquals() with JDK-8044786, but I
remember reasoning that it wasn’t an issue for equals(). Apparently, that was
wrong…
The reason may be that the bug manifests itself only if the value is
actually stored as an object. If it is stored as primitive it will be
wrapped as two different java.lang.Double instances s for both sides of
the comparison, making it behave as expected.
Now even with optimistic types disabled, we have code that narrows the
type of new properties so it will be of double type. (I wonder if it's a
good idea to do that without optimstic types / dual fields?)
I've updated the webrev in-place to make that mechanism more explicit in
the test comments and code by mixing in some object assignments.
http://cr.openjdk.java.net/~hannesw/8141407/webrev/
Hannes
Attila.
On Nov 23, 2015, at 3:35 PM, Hannes Wallnöfer <hann...@gmail.com> wrote:
Please review JDK-8141407: Wrong evaluation of a != a when a = NaN:
http://cr.openjdk.java.net/~hannesw/8141407/
Thanks,
Hannes
