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:
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 +
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.
On Mon, Apr
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);
