You’re right. I was referring to behavior of the typeof operator. Hannes
> Am 17.08.2016 um 08:45 schrieb Attila Szegedi <szege...@gmail.com>: > > 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, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> >> wrote: >> >> 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 >>> <joaovaran...@inpaas.com>: >>> >>> 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" >>> >> >
