Well, first of all:
float and double are two primitive types, BigDecimal is a class. It doesn't just represent numbers but operations too.

A float is a decimal numeric type represented with 32 bit. A double is a 64 bit decimal number, so it can represent larger values than a float.

On javadoc you will find a quite clear description of BigDecimal class instead, but look at one of the many constructors of that class:

BigDecimal(BigInteger unscaledVal, int scale)
Translates a BigInteger unscaled value and an int scale into a BigDecimal.

This constructor uses a BigInteger to represent arbitrary-precision integers values on the left of the decimal point, and an int (32 bit) to represent values on the right of the decimal point.

So BigDecimal is able to represent very precise decimal values and you should typically use it when you need really accurate computations.

Another often used constructor of BigDecimal is that which takes a String. This will use the exact number from the String without losing any of the precision. Compare this with double:
Because BigDecimal never rounds automatically or loses precision it is highly preferred in calculations where automatic rounding or losing precision could be disastrous - like financial programs.

That said, BigDecimal does come with a few drawbacks:
- they take up more memory than double
- they are always stored in the heap, not in the stack like double local variables
- you can't use +, -, * etc, but have to call methods like add, subtract and multiply. These all require another BigDecimal as operand so again more memory

The latter may be changed in Java 7; there have been rumours of adding support for +, -, * and / for BigDecimal and BigInteger as has been done with + and String.

Rob Prime wrote:Because BigDecimal never rounds automatically or loses precision

In some situations, it' s impossible to avoid losing precision, even with BigDecimal. Try dividing 2 by 3 with BigDecimal without losing precision at some point.

Rob Prime wrote:they are always stored in the heap

Well, almost always. Except when they aren't. Like most sentences with "always" (without "almost"), this is, actually, not always true. Look up "escape analysis" for details if you want them.