Yes, I had to freshen up on floating point precision. It's odd to use a double for a long value but you have no corruption up to 2^53.
Advertising
So, indeed, this might be a problem for Google, but not for normal scripts. --emi On Thu, Oct 13, 2016 at 2:05 PM, Attila Szegedi <szege...@gmail.com> wrote: > I think Emilian’s example of File.length() is actually in favor of not > converting Longs to doubles automatically. Although to be fair, 53 bits of > double precision can still correctly represent a file length of up to cca. > 8 petabytes if I’m not mistaken, so… probably Not a Problem For Most > People™ yet unless you run a data warehouse :-) > > As a funny aside, I remember being back at Twitter around the time we > crossed the 53th significant bit mark for unique IDs that were used for > various entities internally (including tweet IDs) and had to change their > representation in JSON from number to string otherwise some clients had > trouble parsing ‘em… It’s just the way JS is. > > Attila. > > > On 12 Oct 2016, at 19:08, Hannes Wallnöfer <hannes.wallnoe...@oracle.com> > wrote: > > > > I am sorry about the inconvenience this is causing. ECMA defines > JavaScript numbers as 64 bit doubles, and Java longs do not fit into this > without either losing precision for large values or breaking the spec > elsewhere. We did a lot of soul-searching on this and don’t think there’s > any other solution. > > > > However, it is not too hard to work around this. A Long object can be > converted to a number calling the global Number() function without new > keyword, or, if that is too verbose, by just using the unary + operator: > > > > Number(javaLong) // converts javaLong to a number > > +javaLong // same > > > > This will work seamlessly with older versions of Nashorn where javaLong > is already considered a number, so no special casing is required. Again, > I’m sorry for the inconvenience, but this is how things are and we are not > planning to go back. > > > > Hannes > > > > > >> Am 12.10.2016 um 17:58 schrieb Emilian Bold <emilian.b...@gmail.com>: > >> > >> João, I actually remember your thread but I assumed it's about Long > >> instances. Somehow it didn't click that it's about long primitives too. > >> > >> java.io.File.length() is something I easily see anybody using in some > basic > >> Nashorn script without expecting the value to be corrupted. > >> > >> > >> --emi > >> > >> On Wed, Oct 12, 2016 at 6:42 PM, João Paulo Varandas < > >> joaovaran...@inpaas.com> wrote: > >> > >>> Joerg/Emilian. > >>> > >>> This is a questioning we've raised some time ago. > >>> I still cannot upgrade from revision 91 because of the side effects of > >>> this change ... > >>> > >>> It seems that we need some wrapping/unwrapping when working with > 'Long's > >>> in Nashorn, I don't like this either, but it seems that there's a gap > >>> between Long, Double and JSNumber max values which was bringing a loss > of > >>> precision with long values in Nashorn. Thus, Long is now "object" ... > >>> > >>> Check out: > >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016- > August/006450.html > >>> > >>> > >>> > >>> > >>> *João Paulo Varandas*+55 11 99889-2321 > >>> joaovaran...@inpaas.com > >>> > >>> > >>> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.b...@gmail.com>: > >>> > >>>> I just read a few of the bugs linked and it does seem worrisome. So, > >>>> Nashorn cannot reliably be used as a glue between Java code that uses > >>>> longs? > >>>> > >>>> > >>>> --emi > >>>> > >>>> On Wed, Oct 12, 2016 at 5:10 PM, Frantzius, Jörg < > >>>> joerg.frantz...@aperto.com > >>>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> as of JDK 1.8.0_101, the following JUnit test fails: > >>>>> > >>>>> @Test > >>>>> public void testLongIsNumber() { > >>>>> jdk.nashorn.api.scripting.ScriptObjectMirror isNumberFunction > = > >>>>> eval("function isNumber(arg) {\n" + > >>>>> " return typeof arg === 'number';\n" + > >>>>> "}\n" + > >>>>> ""); > >>>>> Object result = isNumberFunction.call(isNumberFunction, 1L); > >>>>> assertTrue((boolean) result); > >>>>> } > >>>>> > >>>>> This breaks e.g. Nodyn, where Long numbers resulting from > >>>>> java.io.File.length() are passed into https://nodejs.org/api/util. > >>>>> html#util_util_isnumber_object , resulting in some „if" clause now > >>>> taking > >>>>> the wrong turn. I guess this is a side-effect of > >>>>> https://bugs.openjdk.java.net/browse/JDK-8144020 . > >>>>> > >>>>> While I’m probably able to patch this in Nodyn, I find it a bit > >>>>> frightening that any other code out there that relies on Longs being > >>>> typeof > >>>>> ‚number‘ will break now, in particular because there is a lot of JDK > API > >>>>> that returns Long... > >>>>> > >>>>> Regards, > >>>>> Jörg > >>>>> > >>>>> > >>>>> --- > >>>>> > >>>>> Dipl. Inf. Jörg von Frantzius, Technical Director > >>>>> > >>>>> E-Mail joerg.frantz...@aperto.com > >>>>> > >>>>> Phone +49 30 283921-318 > >>>>> Fax +49 30 283921-29 > >>>>> > >>>>> Aperto AG – An IBM Company > >>>>> Chausseestraße 5, D-10115 Berlin > >>>>> http://www.aperto.com<http://www.aperto.de/> > >>>>> http://www.facebook.com/aperto > >>>>> https://www.xing.com/companies/apertoag > >>>>> > >>>>> HRB 77049 B, AG Berlin Charlottenburg > >>>>> Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan > Haagen, > >>>>> Daniel Simon > >>>>> Aufsichtsrat: Matthew Candy (Vorsitzender) > >>>>> > >>>>> > >>>> > >>> > >>> > >>> "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" > >>> > >>> > > > >
