Introduction

In Java, double and BigDecimal solve different numeric problems. double is fast and approximate because it uses binary floating-point arithmetic, while BigDecimal is slower but gives explicit decimal precision and controlled rounding, which is why it is preferred for money and other exact decimal rules.

What double Is Good At

double is a 64-bit IEEE 754 floating-point type. It is ideal when:

• small rounding error is acceptable
• speed matters
• the calculations are scientific or approximate by nature

Example:

1public class Main {
2    public static void main(String[] args) {
3        double a = 0.1;
4        double b = 0.2;
5        double c = a + b;
6        System.out.println(c);
7    }
8}

The output is not exactly 0.3 because many decimal fractions cannot be represented exactly in binary floating point.

That is not a Java bug. It is how floating-point math works.

What BigDecimal Is Good At

BigDecimal stores decimal values with arbitrary precision and explicit scale management:

1import java.math.BigDecimal;
2
3public class Main {
4    public static void main(String[] args) {
5        BigDecimal a = new BigDecimal("0.1");
6        BigDecimal b = new BigDecimal("0.2");
7        BigDecimal c = a.add(b);
8        System.out.println(c);
9    }
10}

This prints exactly 0.3.

That is why financial systems, tax calculations, and billing engines usually rely on BigDecimal instead of double.

The Constructor Detail Matters

If you choose BigDecimal, construct it carefully:

BigDecimal good = new BigDecimal("0.1");
BigDecimal bad = new BigDecimal(0.1);

The string constructor preserves the intended decimal value. The double constructor captures the binary floating-point approximation of 0.1, which defeats much of the reason for using BigDecimal in the first place.

This is one of the most important practical differences to remember.

Performance And Ergonomics Tradeoff

double is easier to write and faster to compute with:

double total = price * quantity;

BigDecimal is more explicit and more verbose:

BigDecimal total = price.multiply(quantity);

It also requires deliberate rounding decisions:

1import java.math.RoundingMode;
2
3BigDecimal result = new BigDecimal("10")
4    .divide(new BigDecimal("3"), 2, RoundingMode.HALF_UP);

That explicitness is a benefit when your business rules actually care about rounding policy.

Choose Based On Domain, Not Habit

Use double when the domain tolerates approximation, such as graphics, physics simulation, telemetry, or statistical calculations where tiny binary rounding noise is acceptable.

Use BigDecimal when decimal correctness is part of the business rule, such as:

• prices
• taxes
• exchange calculations
• invoices
• balances

The mistake is not choosing the "wrong" class abstractly. The mistake is choosing a numeric type that does not match the meaning of the data.

This is also why many teams establish a domain rule such as "currency values are always BigDecimal" so the choice is consistent across services, persistence code, and reporting logic.

Common Pitfalls

One common mistake is using double for money because it feels simpler. The result is often subtle rounding drift that appears later in totals or reconciliation.

Another issue is using new BigDecimal(0.1) instead of the string constructor or BigDecimal.valueOf(0.1).

A third problem is switching to BigDecimal but still thinking in floating-point style, for example by ignoring scale and rounding mode requirements during division.

Finally, some teams use BigDecimal everywhere, even where approximate math would be simpler and faster with no business downside.

Summary

• 'double is fast and approximate because it uses binary floating-point arithmetic.'
• 'BigDecimal is slower but gives explicit decimal precision and rounding control.'
• Use double for approximate scientific or general numeric work.
• Use BigDecimal for money and other exact decimal business rules.
• If you use BigDecimal, prefer string input or BigDecimal.valueOf(...) over the raw double constructor.
• Choose deliberately so precision requirements are designed in, not patched later.