Unexpected equality behavior (java.lang.Long)

[Hannes Wallnöfer]

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 should allow people to deal with longs as numbers, assuming they are all right with an eventual loss of presentation. 

This needs some discussion and thinking and experimentation. I’ll get back to you after the weekend.

Hannes



> Am 05.08.2016 um 04:40 schrieb João Paulo Varandas <joaovarandas at inpaas.com>:
> 
> 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"