typeof Long is not 'number' anymore

[Emilian Bold]

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