Nashorn does not guarantee the exact Number subtype that will be used to
represent a JS number. From Java code, you need to cast the result to
java.lang.Number type and then call appropriate method like doubleValue
or longValue on it. This "represent most appropriate Number type" helps
in optimizations.
-Sundar
On 9/29/2016 10:00 PM, Frantzius, Jörg wrote:
> Hi,
>
> we have a JUnit test that first evaluates a Javascript file containing this:
>
> function add(a, b) {
> return a + b;
> }
>
> The Java JUnit test itself then evaluates
>
> engine.eval("add(4, 5)")
>
> Just until 1.8.0_91, this used to return a 9L Long number. With 1.8.0_101,
> this suddenly returns a Double object 9D.
>
> When directly evaluating the addition operation:
>
> eval("4 + 5")
>
> an Integer 9 is returned, both with 1.8.0_101 and 1.8.0_91.
>
> Is this intended behaviour, or is this a bug?
>
> Thx for responses + 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)
>
