Avoid Costly Bugs: Mastering BigDecimal Pitfalls in Java

Background

Having worked on financial projects for a long time, I am very familiar with BigDecimal, and have seen many cases where misuse leads to monetary losses.

If your project involves monetary calculations, you should study this article to learn BigDecimal comprehensively.

BigDecimal Overview

Java provides the java.math.BigDecimal class for precise arithmetic beyond 16 significant digits. While double handles up to 16 digits, many applications require higher precision.

For non‑critical numbers, float and double are fine, but they lose precision when converting from String . For exact results, use BigDecimal .

BigDecimal offers methods corresponding to +, -, *, / and is immutable; each operation creates a new object, so remember to store the result.

Four BigDecimal Pitfalls

Understanding these pitfalls helps you spot faulty code and avoid costly bugs.

1. Floating‑point pitfalls

Using float or double can produce approximate values instead of exact ones.

<code>@Test
public void test0(){
  float a = 1;
  float b = 0.9f;
  System.out.println(a - b);
}
</code>

The result is 0.100000024 , not 0.1 , because 0.1 cannot be represented exactly in binary.

Even with BigDecimal, precision issues can arise if you construct it from a floating‑point value.

<code>@Test
public void test1(){
  BigDecimal a = new BigDecimal(0.01);
  BigDecimal b = BigDecimal.valueOf(0.01);
  System.out.println("a = " + a);
  System.out.println("b = " + b);
}
</code>

Output:

<code>a = 0.01000000000000000020816681711721685132943093776702880859375
b = 0.01
</code>

The difference is caused by passing a double to the constructor, which retains the approximate binary value.

BigDecimal.valueOf avoids this by converting the double to a string first:

<code>public static BigDecimal valueOf(double val){
    return new BigDecimal(Double.toString(val));
}
</code>

Conclusion: Prefer constructing BigDecimal from a String or using BigDecimal.valueOf .

2. Equality vs. compareTo

How should you compare two BigDecimal values?

<code>@Test
public void test2(){
  BigDecimal a = new BigDecimal("0.01");
  BigDecimal b = new BigDecimal("0.010");
  System.out.println(a.equals(b));
  System.out.println(a.compareTo(b));
}
</code>

equals checks both value and scale, so it returns false . compareTo compares only the numeric value, returning 0 .

Use compareTo for magnitude comparison; use equals only when scale must match.

3. Setting scale pitfalls

Omitting precision and rounding mode can cause runtime exceptions.

<code>@Test
public void test3(){
  BigDecimal a = new BigDecimal("1.0");
  BigDecimal b = new BigDecimal("3.0");
  a.divide(b);
}
</code>

This throws ArithmeticException because the division results in a non‑terminating decimal.

<code>java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
    at java.math.BigDecimal.divide(BigDecimal.java:1690)
</code>

Specify precision and rounding mode:

<code>@Test
public void test3(){
  BigDecimal a = new BigDecimal("1.0");
  BigDecimal b = new BigDecimal("3.0");
  BigDecimal c = a.divide(b, 2, RoundingMode.HALF_UP);
  System.out.println(c);
}
</code>

Result: 0.33 .

Rounding modes defined in java.math.RoundingMode :

UP – round away from zero.

DOWN – round toward zero (truncate).

CEILING – round toward positive infinity.

FLOOR – round toward negative infinity.

HALF_UP – classic “round half up”.

HALF_DOWN – round half down.

HALF_EVEN – “banker’s rounding”.

UNNECESSARY – assert exact result, otherwise throw exception.

Most people use HALF_UP .

4. String conversion pitfalls

Printing a BigDecimal directly may produce scientific notation.

<code>@Test
public void test4(){
    BigDecimal a = BigDecimal.valueOf(35634535255456719.22345634534124578902);
    System.out.println(a.toString());
}
</code>

Output: 3.563453525545672E+16 .

Three conversion methods:

toPlainString() – no scientific notation.

toString() – uses scientific notation when needed.

toEngineeringString() – uses engineering notation (exponent multiples of 3).

Conclusion: Choose the appropriate method based on display needs; toPlainString() is commonly used.

Summary

This article presented four common BigDecimal pitfalls—floating‑point inaccuracies, equality vs. compareTo, missing scale/rounding, and string conversion—along with best‑practice recommendations such as using String constructors or valueOf , preferring compareTo for value comparison, always specifying precision and a rounding mode, and selecting the proper string‑conversion method. While BigDecimal offers superior precision, it incurs performance overhead, so use it only when necessary and follow the guidelines to avoid errors.