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