Name: jl125535 Date: 11/08/2001


java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

Consider the following code:

x.setField(value);

By convention, this method implies a request to change the internal
state of x.

However, the setScale() method of BigDecimal violates this convention.
Rather than a request to change the internal state of the callee,
BigDecimal.setScale() is a constructor that does nothing
to the callee.

These unexpected semantics will cause misuse of BigDecimal.
The original submitter of this report originally thought there was a bug in
scale(), because he expected setScale() to update the callee.

Here are two suggestions for clarifying this part of BigDecimal:
1. Deprecate setScale().

2. Decide how to create copies of existing BigDecimal objects that
   have different scales. There are several options.
- Classic factories (see Design Patterns by Gamma, et al)
- Static factories (see Effective Java by Bloch)
- Copy constructors
- "get" methods, such as getScaledNumber()
(Review ID: 135191)
======================================================================