Unexpected equality behavior (java.lang.Long)

[João Paulo Varandas]

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 for discussion ...
--

2 Long values returned from a database and sent to a javascript evaluation
code can't be compared the way it should in JavaScript...  If I have some
validation code, I don't know if the source is some JavaScript input
(number), or the source is a database query (object/Long/Integer/Double).

It's really hard to decide when sometimes x==y should be compared as
x.equals(y) and sometimes not... and sometimes, at the same point in code I
should do a lot of conditional operations, to resolve a simple
comparison... and that comparison does not work if the data source is a
Java object or a JavaScript object.

The problem with the current solution is that comparison between different
types would never work ...

Seeing that
jjs> new java.lang.Long(2147483648) == "2147483648"
returns true

But
jjs> new java.lang.Long(2147483648) == new java.lang.Long(2147483648)
returns false

Is something really hard to accept ...
And that "equals" approach will work ONLY if I compare Long to Long. And I
see this as a regression when talking about evaluating JavaScript code.



Sorry about the long post, but I would really appreciate if we could
revalidate this and think about what the current situation represents from
ecmascript's point of view.





-08-04 22:43 GMT-03:00 João Paulo Varandas <joaovarandas at inpaas.com>:

> 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 evaluation inside the JVM.
>
>
> Comparison operators inside the script engine follow JavaScript rules and
> not Java rules.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *João Paulo Varandas*+55 11 99889-2321
> joaovarandas at inpaas.com
>
>
> 2016-08-04 20:08 GMT-03:00 Tomáš Zíma <tomas at tzima.cz>:
>
>> 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 java data
>>> types (java.lang.Long).
>>>
>>> Check that:
>>> jjs> new java.lang.Long(10) == new java.lang.Long(10)
>>> false
>>>
>>> Oops!?
>>>
>>> See the gist:
>>> https://gist.github.com/joaovarandas/51567bd3b576d48a4c574d60d5a60ba3
>>>
>>> The results for all types should be ...
>>> ==    true
>>> ===   true
>>> equals true
>>>
>>> But for java.lang.Long and java.math.BigDecimal:
>>> ==    false
>>> ===   false
>>> equals true
>>>
>>> Maybe we could expand the test to other classes too, but the issue ...
>>> - It does happen in 1.8.0_101.
>>> - It does not 1.8.0_91.
>>> - It does happen with other classes (BigDecimal).
>>> - It does not happen with String.
>>> - It does not happen with Integer.
>>>
>>>
>>> I understand this is not an expected behavior. For now I'm rolling back
>>> to 1.8.0_91 in my environments.
>>>
>>>
>>>
>>> Do you me to file a bug?
>>>
>>> Thanks
>>> J
>>>
>>>
>>
>>
>

-- 
"Esta mensagem, incluindo seus anexos, pode conter informacoes 
confidenciais e privilegiadas. 
Se voce a recebeu por engano, solicitamos que a apague e avise o remetente 
imediatamente. 
Opinioes ou informacoes aqui contidas nao refletem necessariamente a 
posicao oficial da Plusoft."

"Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO 
AMBIENTE"