Longs aren't numbers in Java 8u162

[Ryan Berdeen]

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?

[Jesus Luzon]

This seems like it could be a side effect of a bug I reported where using a
number as the key in an object in Nashorn made an array of the at least the
size of the number and then inserted in the index of the number specified.
The bug was fixed around that version that you mention.

Post by Ryan Berdeen
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
$ 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?

[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

Post by Ryan Berdeen
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
$ 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?

[Anders Rundgren]

Post by 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.

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

Post by Hannes Wallnöfer
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

Post by Ryan Berdeen
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
$ 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?