Hi Sundar, so wouldn’t an Integer be the most appropriate Number type to represent the number 9? Suddenly running on floating point arithmetics where it used to be integer arithmetics is kind of like shaking the ground.
My problem is that some complex application code is now breaking that seems to be doing arithmetics for things like buffer sizes. With JDK 1.8.0_101 I’m suddenly seeing a java.nio.BufferOverflowException where there was none until 1.8.0_91, and it didn’t look like a bug in java.nio in the debugger. At the same time our JUnit test rang the alarm that arithmetics changed from Integer to Floating Point under the hood. So far it admittedly is speculation on my side that this change from Long to Double is the reason, but I’m just before delving into debugging tons of complex open source javascript code... At any rate, I would think that Integer is most appropriate Number type for representing integral numbers until MAX_INT? 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) Am 30.09.2016 um 05:26 schrieb Sundararajan Athijegannathan <sundararajan.athijegannat...@oracle.com<mailto:sundararajan.athijegannat...@oracle.com>>: 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<mailto: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)
