I have to live in the 1.4 world for this project so something like
BigDecimal sysid = new BigDecimal(50000365566.0000);
System.out.println( String.format("%09.4f", sysid));
isn't supported in 1.4
And unfortunately the simple toString() method always chops off the decimal and training numbers.
This seems like such a simple problem but it has me totally stumped (not a hard feat since I am new to Java). Any one have a suggestion or a like I can follow?
An example of what I meant:
You'll see that the first two printed values are not what you specified they should be.
BigDecimal setScale(int scale)
BigDecimal setScale(int scale, int roundingMode)
Always best to use setScale(int, int).
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.
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.
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.