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 <joaovaran...@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 > joaovaran...@inpaas.com > > > 2016-08-04 20:08 GMT-03:00 Tomáš Zíma <to...@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"
