Or create the BigDecimal from a String: Not only will this maintain the trailing zeros (also in toString()), but it will also ensure that the exact value is stored. When you create a BigDecimal from a double, that double may already be imprecise (even if you hard-code its value). You don't have this problem when creating BigDecimals from Strings. See our Beginner's FAQ, item #20 for more information.
An example of what I meant:
You'll see that the first two printed values are not what you specified they should be.
G Burk wrote:I have to live in the 1.4 world for this project...
As others have asked: Why?
One other point. If and when you do upgrade, you will also have to change the output command, because the equivalent of BigDecimal.toString() in 1.4 is toPlainString() in 1.5 onwards - a very rare case of Java not being backwards-compatible.
Isn't it funny how there's always time and money enough to do it WRONG?
Stephan van Hulst wrote:How is it not backwards compatible?
Because toString() produces different results in 1.4 and 1.5. I don't know about you, but that's not backwards compatible to me (and the "new look" came as a bit of a shock, I can tell you; I have a fair few classes that relied on the old one).
I suspect they wanted to standardize the toString() format for numeric classes; but to me, 'backwards compatible' would have been adding a 'toNumberString()' method that produces the new format.
Well, unless the format of the toString() result was documented, its return value is an implementation detail and can be changed as desired. However, it does seem to be documented. From the Java 1.4 Javadocs:
Returns the string representation of this BigDecimal. The digit-to- character mapping provided by Character.forDigit(int, int) is used. A leading minus sign is used to indicate sign, and the number of digits to the right of the decimal point is used to indicate scale. (This representation is compatible with the (String) constructor.)
In Java 5, that documentation significantly changed, and I think there is indeed a lack of backwards compatibility here.
Rob Spoor wrote:Well, unless the format of the toString() result was documented, its return value is an implementation detail and can be changed as desired...
True, but I use BigInteger/BigDecimal more than most I suspect, and I was pretty sure it was (thanks for the confirmation, BTW).
It's also the only time I can ever remember them making a change like that, so I can't complain too much.