Longs aren't numbers in Java 8u162

[Hannes Wallnöfer]

Hi Ryan,

Yes, this change was intentional. We were aware at the time that it would cause some problems, but on the other hand treating longs as numbers clashed with the ECMA spec and caused silent loss of precision. 

In most cases there should be simple workarounds, like using the unary + operator to convert an object to a number. Sorry for the inconvenience this has been causing!

Hannes


> Am 01.05.2018 um 00:38 schrieb Ryan Berdeen <rberdeen at hubspot.com>:
> 
> I encountered an issue when upgrading from Java 8u66 to 8u162. In 8u66,
> java.lang.Integer and java.lang.Long both behaved as JS numbers. In 8u162
> (and 10.0.1), Longs behave differently in a way that is breaking my
> application.
> 
>    function test(n) {
>      print(n);
>      print(typeof n);
>      print(n.hasOwnProperty('x'));
>      print();
>    }
> 
>    test(new java.lang.Integer(0));
>    test(new java.lang.Long(0));
> 
> In 8u66, this behaved the same for Integer and Long, but in 8u162, typeof
> returns "object", and the object doesn't have the expected properties:
> 
>    $ jjs longs.js
>    0
>    number
>    false
> 
>    0
>    object
>    longs.js:4 TypeError: n.hasOwnProperty is not a function
> 
> In my application, this came up with values passed through to the engine in
> bindings.
> 
> Is this change intentional? If so, is there a way to revert to the previous
> behavior and if not, is there a way to work around it so that I can update?