DigitList bug in recent patch
Frank Ding
dingxmin at linux.vnet.ibm.com
Wed Mar 27 07:48:23 UTC 2013
Hi guys,
We noticed there is a recent change (patch @
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/bc1f16f5566f ) that changed
the behavior of the following program.
import java.math.RoundingMode;
public class TestNumberFormat {
public static void main(String[] args) {
java.text.NumberFormat numberFormat =
java.text.NumberFormat.getInstance(
java.util.Locale.US);
double v = 78.00005;
numberFormat.setMaximumFractionDigits(4);
numberFormat.setRoundingMode(RoundingMode.HALF_EVEN);
numberFormat.setMinimumFractionDigits(0);
numberFormat.setGroupingUsed(false);
String ret = numberFormat.format(v);
System.out.println(ret);
}
}
Note the rounding mode HALF_EVEN and the expected output should be "78"
which can also be verified by running previous jdk (before b73).
Stepping into code and the suspicious code is in
DigitList.shouldRoundUp(). allDecimalDigits is false so true is
returned, causing the last digit in fraction part to be 1.
case HALF_EVEN:
// Implement IEEE half-even rounding
if (digits[maximumDigits] > '5') {
return true;
} else if (digits[maximumDigits] == '5' ) {
if (maximumDigits == (count - 1)) {
// the rounding position is exactly the last
index :
if (alreadyRounded)
// If FloatingDecimal rounded up (value was
below tie),
// then we should not round up again.
return false;
if (!allDecimalDigits)
// Otherwise if the digits dont represent
exact value,
// value was above tie and FloatingDecimal
truncated
// digits to tie. We must round up.
return true;
Since I am not familiar of the numeric conversion, can any one shed your
light on it?
Best regards,
Frank
More information about the core-libs-dev
mailing list