Current JDK gives the output of "78.0001".
Best regards,
Frank
On 3/27/2013 3:48 PM, Frank Ding wrote:
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