Name: rm29839 Date: 11/12/97
Using NumberFormat we sould get formatted strings.
Suppose I perform all my Money arthimetic using
double type. Now I Need to round the number to the
nearest penny, I should be able to do that by
associating a Precision Class to Format which will
produce the correct String.
This is just a suggession
(Review ID: 19509)
======================================================================
Name: jl125535 Date: 01/23/2002
It might be a good idea for java.text.NumberFormat to support rounding modes besides half_even (see getIntegerInstance()). A feature like java.lang.BigDecimal.setScale(int scale, int roundingMode) would allow the selection of a rounding mode.
(Review ID: 138628)
======================================================================
Name: gm110360 Date: 02/16/2002
FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)
-- same problem with
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
FULL OPERATING SYSTEM VERSION : Windows NT Version 4.0
Build 1381, Service Pack 6
A DESCRIPTION OF THE PROBLEM :
DecimalFormat: A pattern like "##0.000E0" does not produce
three fraction digits if the fraction part is close or equal
to zero.
However, this is needed in ouptut of
- results from scientific computation
- y-Axis tic labels in charting applications
There is a related RFE, that is driven by the same
requirement: 4092330
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the attached source "DecimalFormatTest.java"
2. Execute
3. Look at the console output
EXPECTED VERSUS ACTUAL BEHAVIOR :
--Actual output of DecimalFormatTest.java:
12.345E3
12.00E3
12.001E3
12.0003E3
12.0007E3
12.00E3
--Expected:
12.345E3
12.000E3
12.001E3
12.000E3
12.001E3
12.000E3
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.text.DecimalFormat;
public class DecimalFormatTest {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat("##0.000E0"); // three fraction digits !
System.out.println(df.format(12345.0)); // "12.345E3", OK
System.out.println(df.format(12000.0)); // "12.00E3", BUG
System.out.println(df.format(12001.0)); // "12.001E3", OK
System.out.println(df.format(12000.3)); // "12.0003E3", BUG
System.out.println(df.format(12000.7)); // "12.0007E3", BUG
System.out.println(df.format(12000.03)); // "12.00E3", BUG
}
}
---------- END SOURCE ----------
(Review ID: 139590)
======================================================================
###@###.### 11/5/04 00:50 GMT
Using NumberFormat we sould get formatted strings.
Suppose I perform all my Money arthimetic using
double type. Now I Need to round the number to the
nearest penny, I should be able to do that by
associating a Precision Class to Format which will
produce the correct String.
This is just a suggession
(Review ID: 19509)
======================================================================
Name: jl125535 Date: 01/23/2002
It might be a good idea for java.text.NumberFormat to support rounding modes besides half_even (see getIntegerInstance()). A feature like java.lang.BigDecimal.setScale(int scale, int roundingMode) would allow the selection of a rounding mode.
(Review ID: 138628)
======================================================================
Name: gm110360 Date: 02/16/2002
FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)
-- same problem with
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
FULL OPERATING SYSTEM VERSION : Windows NT Version 4.0
Build 1381, Service Pack 6
A DESCRIPTION OF THE PROBLEM :
DecimalFormat: A pattern like "##0.000E0" does not produce
three fraction digits if the fraction part is close or equal
to zero.
However, this is needed in ouptut of
- results from scientific computation
- y-Axis tic labels in charting applications
There is a related RFE, that is driven by the same
requirement: 4092330
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the attached source "DecimalFormatTest.java"
2. Execute
3. Look at the console output
EXPECTED VERSUS ACTUAL BEHAVIOR :
--Actual output of DecimalFormatTest.java:
12.345E3
12.00E3
12.001E3
12.0003E3
12.0007E3
12.00E3
--Expected:
12.345E3
12.000E3
12.001E3
12.000E3
12.001E3
12.000E3
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.text.DecimalFormat;
public class DecimalFormatTest {
public static void main(String[] args) {
DecimalFormat df = new DecimalFormat("##0.000E0"); // three fraction digits !
System.out.println(df.format(12345.0)); // "12.345E3", OK
System.out.println(df.format(12000.0)); // "12.00E3", BUG
System.out.println(df.format(12001.0)); // "12.001E3", OK
System.out.println(df.format(12000.3)); // "12.0003E3", BUG
System.out.println(df.format(12000.7)); // "12.0007E3", BUG
System.out.println(df.format(12000.03)); // "12.00E3", BUG
}
}
---------- END SOURCE ----------
(Review ID: 139590)
======================================================================
###@###.### 11/5/04 00:50 GMT
- duplicates
-
JDK-4482734 [Fmt-Nu] RFE: DecimalFormat rounding mode should be configurable
-
- Closed
-
-
JDK-6609738 Provide member function for changing rounding method in NumberFormat
-
- Closed
-
- relates to
-
JDK-6285664 [Fmt-Nu] Incorrect output with NumberFormat scientific notation
-
- Closed
-