As its name suggests it is for big decimals, that is values that exceed the primitive floating point ranges. Not sure about the sql question. You should use it if you need to manipulate floating point values larger then then the primitive values or the mathematical result might exceed it. I remember reading somewhere, probably Dr. Dobbs Journal, that it shouldn't be used for monetary values.

edit: I could be wrong on my recollection, but at any rate extreme care should be used when manipulating real money values. That goes without saying no matter what API you use. [ August 16, 2006: Message edited by: Rusty Shackleford ]

"Computer science is no more about computers than astronomy is about telescopes" - Edsger Dijkstra

According to the Java tutorial, in the latest edition, BigDecimal is what one is supposed to use for money. It is one of the two classes in the java.math. package, the other being BigDecimal. Both are designed for precise calculation in decimal numbers outwith the range of the primitive types.

The only way to learn about a class is to make up a little app which uses it, and play with it. Try it, and post your results on this thread.

Originally posted by Rusty Shackleford: I remember reading somewhere, probably Dr. Dobbs Journal, that it shouldn't be used for monetary values.

Maybe you got confused - you should never use float or double for money values, you should use BigDecimal instead.

BigDecimal allows you to work with arbitrary precision decimal values. The primitive types float and double have limited precision, and you can quickly get problems with rounding errors if you don't watch out. Rounding errors are unacceptable for software that deals with money. You don't want money to disappear or magically appear, even if it is just a few cents, because of rounding errors.

So the main reason to use BigDecimal is when you need to do precise calculations in which rounding errors are not acceptable. [ August 16, 2006: Message edited by: Jesper Young ]

So the main reason to use BigDecimal is when you need to do precise calculations in which rounding errors are not acceptable.

That struck me as funny for some reason. Rounding is a loss of accuracy error isn't it? So maybe BigDecimal makes rounding errors predictable?

Anyhow, BigD does money as you'd expect, like your bank or your accountant or COBOL would. If we say that behavior is "correct" then rounding with floats leads to "errors" for sure.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com