typeof Long is not 'number' anymore

Thu Oct 13 11:05:25 UTC 2016

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"
>>> 
>>> 
> 