Issue  Fix Version  Assignee  Priority  Status  Resolution  Resolved In Build 

JDK8142274  emb9  Hannes Wallnoefer  P3  Resolved  Fixed  team 
JDK8140997  8u91  Hannes Wallnoefer  P3  Resolved  Fixed  b01 
JDK8136921  8u72  Hannes Wallnoefer  P3  Resolved  Fixed  b01 
JDK8147366  emb8u75  Hannes Wallnoefer  P3  Resolved  Fixed  b01 
This bug was reported via nashorndev http://mail.openjdk.java.net/pipermail/nashorndev/2015September/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?
Observed behaviour:
> $ jjs version
> nashorn 1.8.0_60
> jjs> 0.5.toFixed()
> 0
> jjs> 0.5.toFixed()
> 0
Expected behaviour:
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
20.1.3.3  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.

Esben Andreasen

His interpretation seems right.
See spec. section:
https://es5.github.io/#x15.7.4.5
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.
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?
Observed behaviour:
> $ jjs version
> nashorn 1.8.0_60
> jjs> 0.5.toFixed()
> 0
> jjs> 0.5.toFixed()
> 0
Expected behaviour:
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
20.1.3.3  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.

Esben Andreasen

His interpretation seems right.
See spec. section:
https://es5.github.io/#x15.7.4.5
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.
 backported by

JDK8136921 Number.prototype.toFixed returns wrong string for 0.5 and 0.5
 Resolved

JDK8140997 Number.prototype.toFixed returns wrong string for 0.5 and 0.5
 Resolved

JDK8142274 Number.prototype.toFixed returns wrong string for 0.5 and 0.5
 Resolved

JDK8147366 Number.prototype.toFixed returns wrong string for 0.5 and 0.5
 Resolved