Name: jl125535 Date: 08/14/2003
A DESCRIPTION OF THE REQUEST :
This is a flaw of the object oriented paradigm. As with most other such methods, when e.g. bigDecimal.add(val) is called, the usual oo programmer thinks of the following behaviour: the value "val" is added to the BigDecimal object "bigDecimal", so that the value of the bigDecimal object changes. The current BigDecimal API instead returns the result of this math operation leading to a bad style like
sum = sum.add(value);
instead of the expected oo style
sum.add(value);
In addition, when adding values (or doing any other math operations) in a loop with lots of values, a new object is created for each math operation which leads to poor performance.
The same is valid vor abs(), add(), divide(), multiply(), negate(), setScale(), subtract(). In addition, the methods scale(), signum(), max(), min() should be named getScale(), getSignum(), getMax(), getMin() as they return values.
This RFE also applies to BigInteger.
JUSTIFICATION :
This class needs an improved API as new developers get problems over and over again with these unlucky method names and return values. Especially the scale() and setScale() methods get mixed up very often!
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
abs(), add(), divide(), multiply(), negate(), setScale(), subtract() should change the value of the BigDecimal object instead of returning a new object.
ACTUAL -
abs(), add(), divide(), multiply(), negate(), setScale(), subtract() return new BigDecimal objects instead of changing the current object.
CUSTOMER SUBMITTED WORKAROUND :
No really workaround, as superfluous objects are still created: write a subclass of BigDecimal which does the same but with a clean API.
(Incident Review ID: 186248)
======================================================================
- relates to
-
JDK-4524984 BigDecimal.setScale() has unexpected semantics
-
- Closed
-