This bug was reported via nashorn-dev http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005142.html
Email content below for reference:
The implementation of Number.prototype.toFixed seems to be wrong in
two cases. Can you confirm this, and/or report it on an issue tracker?
> $ jjs -version
> nashorn 1.8.0_60
> jjs> 0.5.toFixed()
> jjs> -0.5.toFixed()
The two results should be 1 and -1 respectively.
I expect this behaviour because that is how I interpret ES5 and ES6
specifications for Number.prototype.toFixed, and because that is the
behaviour that I can observe in Chrome and Firefox.
Extra comments on possible cause of bug:
The interesting part of the ES6 specification is
220.127.116.11 - 10. - a.:
> Let n be an integer for which the exact mathematical value of n /
10^f ��� x is as close to zero as possible. If there are two such n,
pick the larger n.
In the case of `0.5.toFixed()` the expression above becomes:
> n / 10^0 - 0.5 = n / 1 - 0.5 = n - 0.5
which solves to `n = 0` or `n = 1`. It seems that Nashorn picks the
`n = 0` case instead of the `n = 1` case.
His interpretation seems right.
See spec. section:
Step 8 Else, x < 1021
Let n be an integer for which the exact mathematical value of n �� 10f ��� x is as close to zero as possible. If there are two such n, pick the larger n.