JDK-4454738 : Decimal Arithmetic Issue
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.math
  • Affected Version: 1.2.2_10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: sparc
  • Submitted: 2001-05-04
  • Updated: 2002-05-15
  • Resolved: 2002-05-15
Related Reports
Duplicate :  
"on Java's inability to natively perform decimal arithmetic"
The temptation is to use float and double, but these are approximating types and
cannot be used in monetary computation (rounding errors...).
I first experimented with a Lawson-specific Decimal class (I still have the
interface if you'd like) but ultimately settled on BigDecimal.

A related item was the Cobol "compute" verb which has no analog in Java.
One example is the Cobol computation of ecomomic order quantity:

In Java, the solution is rather circumspect but still coherent.
  BigDecimal annualQty, orderCost, carryPct, unitCost;  //assume these have been
initialized correctly
  BigDecimal numerator = new BigDecimal( "2.0" );
  numerator = numerator.multiply( annualQty );
  numerator = numerator.multiply( orderCost );
  BigDecimal denominator = carryPct.multiply( unitCost );
  double eoq =
    Math.sqrt( numerator.doubleValue( ) / denominator.doubleValue( ) );

This example is contrived in that we are already approximating the result with
the .sqrt() function, but our Cobol-migrating to Java programmers face similar
examples each day.
With some native support for a decimal type (such as offered in C#), the
application developer's need for precise decimal arithmetic might be realized.
While BigDecimal offers an expressive set of functions, the developer must be
constantly vigilant of its immutability, sensitivity to doubles, etc.
This really slows the adoption of Java by the mainstream applications developer.

EVALUATION I'm not sure who deals with BigDecimal; it's a library issue,I think. Of course, support for operator overloading might make this more palatable. gilad.bracha@eng 2001-05-04 The concerns being raised in this bug being address by JSR 13. In its current form, JSR 13 proposes to add rounding control (so not all arithimetic is exact) as well as a math library (sqrt, pow, exp, etc.). JSR 13 is preparing to enter the community draft phase. joe.darcy@eng 2001-05-14 Java's current BigDecimal has more capabilities than C#'s decimal (e.g. the ability to do very high precision calculations). Once the jsr 13 changes are incorporated, there will be a convenient mechanism to control the rounding and precision of BigDecimal computations. There are currently no plans to add operator overloading for BigDecimal (or other numeric types) to Java. Closing as a dup of the BigDecimal jsr bug. ###@###.### 2002-05-14