Longs aren't numbers in Java 8u162

[Anders Rundgren]

On 2018-05-02 15:24, Hannes Wallnöfer wrote:
> 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.

Somewhat related issue:
https://github.com/javaee/jsonb-spec/issues/80#issuecomment-383465639
https://cyberphone.github.io/doc/security/draft-rundgren-json-canonicalization-scheme.html#json.bignumbers

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