Re: Unexpected equality behavior (java.lang.Long)

We don't need null checks for primitive types, but ... * Any value inside a Map or a Collection won't be primitive. And could be null. * Also, if we are talking about any record coming from a database, 'null' is there. * Any value not present in a Map is returned as null from the "get" method (f

Re: Unexpected equality behavior (java.lang.Long)

You’re right. I was referring to behavior of the typeof operator. Hannes > Am 17.08.2016 um 08:45 schrieb Attila Szegedi : > > It doesn’t… Null is its own type in JS. The typeof operator returns the > string “object” for a null value as per http://es5.github.io/#x11.4.3, but > that’s (weird JS

Re: Unexpected equality behavior (java.lang.Long)

It doesn’t… Null is its own type in JS. The typeof operator returns the string “object” for a null value as per http://es5.github.io/#x11.4.3 , but that’s (weird JS) special-casing. Internally, Null is a type with one value, null. > On 17 Aug 2016, at 07:56, Hann

Re: Unexpected equality behavior (java.lang.Long)

It’s unfortunate JS considers null to be of type ‚object‘. I think that in most practical circumstances and definitely when a number comes from a Java primitive you can omit the null check as Java primitives can’t be null, though. Hannes > Am 16.08.2016 um 16:16 schrieb João Paulo Varandas : >

Re: Unexpected equality behavior (java.lang.Long)

Hi Hannes. Thanks for reviewing this. Seeing it from this perspective: Longs are just like JS Number wrappers. Made me believe the situation was not that bad too. Telling developers to 'unwrap' numbers using " x = Number(x); " would not be a bad idea. With that in mind, any number comparison w

Re: Unexpected equality behavior (java.lang.Long)

After exploring various options I don’t think there’s anything we can do to go back and treat longs like numbers in Nashorn. The ECMA spec is quite clear that there are numbers and object, and comparison of the latter is by reference, not value. So having some kind of in-between states is not

Re: Unexpected equality behavior (java.lang.Long)

Hi Joao Paulo, thanks for the report. We do realize that this change caused problems for a lot of people, and we are sorry for that, and thinking how we can improve things. I still think we were right to remove longs as internal number representation. But maybe we went to far with this, and s

Re: Unexpected equality behavior (java.lang.Long)

By the way, I just found out some bugs filed about Long objects: https://bugs.openjdk.java.net/browse/JDK-8162771 https://bugs.openjdk.java.net/browse/JDK-8161665 And a twitter discussion: https://twitter.com/provegard/status/755010492112986112 I'd like to bring this up again if we have more room

Re: Unexpected equality behavior (java.lang.Long)

Sorry Tomas. Either you did not read the message(which would be indeed a beginner's mistake), or you are misleading the discussion. What you said, about equality and references would be true if we were talking about Java code. This is jdk8-nashorn's mailing list and I'm talking about JavaScript e

Re: Unexpected equality behavior (java.lang.Long)

A classical beginner's mistake. You are using Java objects and comparing references, not the values, so this is expected behavior. Simply compare the objects using equals(). On 4.8.2016 15:48, João Paulo Varandas wrote: Hi guys! It seems that version 1.8.0_101 has a bug in equality for same j