Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4961944

[Fmt-Nu] DecimalFormat.format should preserve BigDecimal

XMLWordPrintable

    • generic, x86
    • generic, windows_2000



      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

            naoto Naoto Sato
            nlindenbsunw Norbert Lindenberg (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Imported:
              Indexed: