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 <rberd...@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?
