Name: nl37777 Date: 12/01/2003
RFE 4018937 adds the capability to format BigInteger and BigDecimal
without loss of information about magnitude and sign of the numbers.
However, formatting of BigDecimal values may still lose information:
BigDecimal allows multiple representations of most numerical values;
e.g. "1.0" is distinct from "1.00" and "1.0000". The toString method
of BigDecimal and the BigDecimal string constructor are designed to
preserve this representation information. Parsing within DecimalFormat
has been specified to preserve this information by reference to the
BigDecimal(String) constructor, but for formatting the existing
specification does not always allow the preservation of this
information.
The issues to be resolved are:
- For formatting BigDecimal values in a non-exponential format, it may
make sense to keep trailing zeroes in the fractional part in place so
that the number of fraction digits is always max(minimumFractionDigits,
min(maximumFractionDigits, scale)).
- For formatting BigDecimal values in exponential format, we discussed
special-casing the current specification of this case for BigDecimal
such that it preserves the full information in the BigDecimal object,
i.e., takes the string produced by BigDecimal.toString and localizes it
without any other modification.
- Both of these formatting changes would affect the result visible to
clients that already pass in BigDecimal to existing API. They would
therefore have to be controlled by a flag on DecimalFormat. We could
possibly combine this with the new parseBigDecimal flag, or have
separate flags for formatting and parsing. A separate subclass for
BigDecimal formatting might be an alternative.
======================================================================
###@###.### 2004-07-19
CAP member has reported the same problem:
J2SE Version (please include all output from java -version flag):
C:\java\j2sdk1.5.0_beta2\bin>java -version
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)
Does this problem occur on J2SE 1.4 or 1.4.1 or 1.4.2? Yes / No (pick one)
NO
Operating System Configuration Information (be specific):
OS Name Microsoft Windows XP Professional
Version 5.1.2600 Service Pack 1 Build 2600
Bug Description:
Behavior of BigDecimal.toString has changed. In J2SE 1.4.x and prior, the
BigDecimal.toString method returned the string representation of the value
1E-15 as 0.000000000000001. In J2SE 1.5 the toString method returns the
value 1E-15 as 1.0E-15.
This might be done intentionally, but it does cause a problem
in our product which makes J2SE 1.5 not backward compatible with our product.
Steps to Reproduce (be specific):
BigDecimal bd = new BigDecimal("1E-15");
String val = bd.toString();
bd = new BigDecimal(".000000000000001");
val = bd.toString();
The value returned by both two string methods will be different when
run against 1.4 vs 1.5