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 would have to be made unwrapping data first ... But, we would also need to test nulls first, because: While "null == 0" yields false, and obviusly "null === 0" yields false. Number(null) === Number(0) would yield true. Thus, we would need: function unwrapNumber(x) { return x == null ? null : Number(x); } And also, to tell developers to call unwrapNumber() everytime they need to compare a Number ... I don't know if you agree with me, but now I see this as an anti-pattern. --- Anyway... It seems that all the fuzz is because of that "bug" with Long numbers and double. And I'm sorry that I did not look further into that issue. Maybe we should look further into that, and try to make that any number below Number.MAX_SAFE_INTEGER (9007199254740991), work the way is expected inside JS evaluations ... *João Paulo Varandas*+55 11 99889-2321 joaovaran...@inpaas.com 2016-08-16 6:23 GMT-03:00 Hannes Wallnöfer <hannes.wallnoe...@oracle.com>: > 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 really an option. Making longs numbers again would > be quite a small and harmless change within the language (without reverting > to longs as internal data type). Precision would be lowered to doubles for > large longs, but that wouldn’t be a problem for most users. > > However, the problems starts where longs as numbers inherit from > Number.prototype. Of course, all methods in Number.prototype are specified > for double values, and the toString methods collides with toString in > java.lang.Long. Having a toString method that rounds large longs to the > nearest double value is a no-go. Nor is extending all methods in > Number.prototype to handle longs are viable options. > > There is one issue we need to fix to improve handling of longs and other > instances of java.lang.Number though (thanks to Attila for first pointing > this out): Currently, java.lang.Numbers not treated as numbers in the > ToPrimitive operation with Number hint. This means less-than/greater-than > operators will treat those number objects as strings instead of converting > to double. I filed a bug for this, and will back port it to JDK 8u: > > https://bugs.openjdk.java.net/browse/JDK-8163945 > > All things considered, there are some things that make me think the > situation is not as bad as some seem to believe. For one, the new treatment > of Longs (with the fix for the bug above) is consistent with how JavaScript > Number objects/wrappers are treated. Comparing two Number wrappers for the > same value will also evaluate to false with both == and === operators, > while comparing them to the primitive number with == will evaluate to true. > > new Number(1) == new Number(1) // false > new Number(1) === new Number(1) // false > new Number(1) == 1 // true > new Number(1) === 1 // false > > So Longs are just like JS Number wrappers. They are object wrappers for > numeric values. If needed they can easily converted to primitive numbers by > calling the global Number() function without „new“ keyword, eg: > > if (typeof x === „object“) > x = Number(x); > > This is a common pattern in JavaScript even without Java longs, so I think > it’s acceptable. > > Hannes > > > > Am 05.08.2016 um 15:45 schrieb Hannes Wallnöfer < > hannes.wallnoe...@oracle.com>: > > > > 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 < > joaovaran...@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 <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" > > > > -- "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"