typeof Long is not 'number' anymore

Thu Oct 13 11:31:46 UTC 2016

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.

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 <szegedia at 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.wallnoefer at 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.bold at 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 <
> >> joaovarandas at 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
> >>> joaovarandas at inpaas.com
> >>>
> >>>
> >>> 2016-10-12 12:11 GMT-03:00 Emilian Bold <emilian.bold at 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.Frantzius at 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.frantzius at 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"
> >>>
> >>>
> >
>
>