Floating point, rounding and BigDecimal

In Java, 0.1 + 0.2 prints 0.30000000000000004, and 0.1 + 0.2 == 0.3 is false. Nothing is broken: a double is an IEEE 754IEEE 754: The standard for binary floating-point arithmetic that float and double follow: float is binary32 with 24 significant bits, double is binary64 with 53, and every operation rounds its exact result to the nearest representable value. binary64 number with 53 significant bits, and a decimal fraction such as 0.1 cannot be written in base 2 with finitely many digits, so Java rounds it to the closest double it can represent. The tiny differences that follow are normal and predictable.

For measurements and science that is fine, as long as you compare doubles with a tolerance and know what infinity and NaN mean. For money it is not: amounts must be exact and must round the way an invoice says, and that is the job of java.math.BigDecimal, a decimal number with a scale and a rounding mode that you choose. You will see the stored values on JDK 25, step through the sum that misses 0.3, compare and round doubles safely, and split a price into its base and its tax so that the parts always add up.

A double holds the nearest binary fraction

In base 2 the places after the point are worth 1/2, 1/4, 1/8, 1/16 and so on. A value such as 0.75, which is 1/2 plus 1/4, needs two of those places and is stored exactly. One tenth can never be built from them, because 10 is 2 × 5 and no power of two divides by 5, so its binary digits repeat for ever and the double keeps only the first 53 significant bits. new BigDecimal(double) converts a double without any rounding, so it prints the value the double really holds:

// What a double really holds: new BigDecimal(double) shows every digit of the stored value.
void main() {
    IO.println("0.1 + 0.2        = " + (0.1 + 0.2));
    IO.println("0.1 + 0.2 == 0.3 : " + (0.1 + 0.2 == 0.3));
    IO.println("stored 0.1       = " + new BigDecimal(0.1));
    IO.println("stored 0.2       = " + new BigDecimal(0.2));
    IO.println("their exact sum  = " + new BigDecimal(0.1).add(new BigDecimal(0.2)));
    IO.println("0.1 + 0.2 holds  = " + new BigDecimal(0.1 + 0.2));
    IO.println("stored 0.3       = " + new BigDecimal(0.3));
    IO.println("stored 19.99     = " + new BigDecimal(19.99));

    double sum = 0;
    for (int i = 0; i < 10; i++) sum += 0.1;
    IO.println("ten 0.1s added   = " + sum);

    IO.println("gap after 1.0    = " + Math.ulp(1.0));
    long big = 9_007_199_254_740_993L;            // 2 to the power 53, plus 1
    IO.println(big + " as a double = " + (double) big);
}

from session import run, version

version()
run("""
java Stored.java
""")

# openjdk version "25.0.4.1" LTS
$ java Stored.java
0.1 + 0.2        = 0.30000000000000004
0.1 + 0.2 == 0.3 : false
stored 0.1       = 0.1000000000000000055511151231257827021181583404541015625
stored 0.2       = 0.200000000000000011102230246251565404236316680908203125
their exact sum  = 0.3000000000000000166533453693773481063544750213623046875
0.1 + 0.2 holds  = 0.3000000000000000444089209850062616169452667236328125
stored 0.3       = 0.299999999999999988897769753748434595763683319091796875
stored 19.99     = 19.989999999999998436805981327779591083526611328125
ten 0.1s added   = 0.9999999999999999
gap after 1.0    = 2.220446049250313E-16
9007199254740993 as a double = 9.007199254740992E15

The double for 0.1 is a little above 0.1 and the double for 0.2 a little above 0.2, so their sum lands on the double just above 0.3, while the literal 0.3 is stored as the double just below it. Two different doubles, so == is false. Step through the four values the run printed around 0.3:

Adding 0.1 ten times misses 1.0 the same way. Math.ulp(1.0) prints 2.220446049250313E-16: that is the ulpulp: Unit in the last place: the gap between a floating-point number and the next larger one of its type. Math.ulp(1.0) is 2.220446049250313E-16, and the gap grows with the size of the number. of 1.0, how far it is from its neighbour above, and the reason a double carries roughly 15 or 16 decimal digits that you can trust. Whole numbers are exact only up to 2⁵³: the last line shows 9,007,199,254,740,993 coming back as …992, the nearest double.

Printing hides all this. Double.toString writes the fewest digits that still identify the double uniquely, so the double for 0.1 comes out as 0.1 rather than its 55 exact digits after the point; the difference shows only once arithmetic lands on a neighbouring double, as 0.1 + 0.2 does.

JDK 17 made arithmetic identical everywhere, and JDK 19 changed the printing

Two releases changed Java’s floating point, and code written for older JDKs still shows both. Walk through how the rules moved:

Floating-point arithmetic in Java, the operators such as + and * and the conversions between types, gives bit-for-bit identical results on every platform. Before JDK 17 that was guaranteed only inside code marked strictfp; JEP 306 made every floating-point expression strict, so the modifier no longer changes anything and javac says so:

// strictfp was needed before JDK 17 for results that are the same on every machine; now it changes nothing.
strictfp double area(double radius) {
    return Math.PI * radius * radius;
}

void main() {
    IO.println(area(2.5));
}

from session import run, version

version()
run("""
javac Strict.java
java Strict
""")

# openjdk version "25.0.4.1" LTS
$ javac Strict.java
Strict.java:2: warning: [strictfp] as of release 17, all floating-point expressions are evaluated strictly and 'strictfp' is not required
strictfp double area(double radius) {
                ^
1 warning
$ java Strict
19.634954084936208

You can delete strictfp from old code without changing a single result. The methods of Math, such as Math.sin, are a different matter: their documentation allows the last bit to differ from one platform to another, while StrictMath.sin is defined to give the same result everywhere.

Double.toString has followed the shortest-digits rule exactly since JDK 19. Older releases sometimes printed a longer string than needed, with different last digits. The same class, run on JDK 17 and then on JDK 25:

public class Shortest {
    public static void main(String[] args) {
        System.out.println(2e23 + " " + 1e23 + " " + 0.1);
    }
}

from session import run, version

version("17")
run("java Shortest.java", jdk="17")
version()
run("java Shortest.java")

# openjdk version "17.0.20.1"
$ java Shortest.java
1.9999999999999998E23 9.999999999999999E22 0.1
# openjdk version "25.0.4.1" LTS
$ java Shortest.java
2.0E23 1.0E23 0.1

The doubles are the same on both; only the printed text changed. If you compare printed doubles in tests, for example after an upgrade from JDK 17, expect a few of them to look different.

Compare computed doubles with a tolerance

A computed double usually carries some rounding error, so testing it with == demands more precision than the arithmetic delivered. Test whether the two values are near enough to each other instead. Java’s standard library has no ready-made method for this, so write a small one:

// Comparing computed doubles: a relative tolerance, plus an absolute one for values near zero.
boolean close(double a, double b, double relTol, double absTol) {
    return Math.abs(a - b) <= Math.max(relTol * Math.max(Math.abs(a), Math.abs(b)), absTol);
}

void main() {
    double total = 0.1 + 0.2;
    double balance = 0.1 + 0.2 - 0.3;             // should be zero
    IO.println("total == 0.3            : " + (total == 0.3));
    IO.println("close(total, 0.3)       : " + close(total, 0.3, 1e-9, 0));
    IO.println("balance                 = " + balance);
    IO.println("close(balance, 0), rel  : " + close(balance, 0, 1e-9, 0));
    IO.println("close(balance, 0), abs  : " + close(balance, 0, 1e-9, 1e-9));
    IO.println("difference from 0.3     = " + Math.abs(total - 0.3));
    IO.println("relative allowance, 0.3 = " + 1e-9 * Math.max(Math.abs(total), 0.3));
    IO.println("relative allowance, 0   = " + 1e-9 * Math.max(Math.abs(balance), 0));
}

from session import run, version

version()
run("""
java Close.java
""")

# openjdk version "25.0.4.1" LTS
$ java Close.java
total == 0.3            : false
close(total, 0.3)       : true
balance                 = 5.551115123125783E-17
close(balance, 0), rel  : false
close(balance, 0), abs  : true
difference from 0.3     = 5.551115123125783E-17
relative allowance, 0.3 = 3.0000000000000005E-10
relative allowance, 0   = 5.551115123125783E-26

close measures the difference against the bigger of the two magnitudes. With relTol at 1e-9, two values pass when they agree to roughly nine significant digits, whether they are tiny or huge. The idea breaks down next to zero: a relative test scales the allowed difference by the size of the numbers, and when the expected value is 0 the allowed difference shrinks to nothing. So balance, which ought to be 0 but holds 5.6 × 10⁻¹⁷, is rejected. Step through the three calls with the numbers the last three lines of the run printed:

The absTol argument covers the case near zero: it is a difference you accept whatever the sizes. Pick it from what the numbers mean; for lengths in metres, 1e-9 is one nanometre.

Floating point never throws: infinity, NaN and minus zero

Floating-point arithmetic never throws. A result that is too large becomes infinity, and an operation with no sensible answer gives NaNNaN: Not a Number: the double or float that 0.0 / 0.0 and Math.sqrt(-1) give. Every comparison with NaN is false, itself included, so it is found with Double.isNaN(x), never with ==., “not a number”:

// Infinity, NaN and the two zeros: double arithmetic never throws.
void main() {
    double nan = 0.0 / 0.0;
    IO.println("1.0 / 0      = " + 1.0 / 0 + ",  -1.0 / 0 = " + -1.0 / 0);
    IO.println("0.0 / 0.0    = " + nan + ",  Math.sqrt(-1) = " + Math.sqrt(-1));
    IO.println("nan == nan   : " + (nan == nan) + ",  Double.isNaN(nan): " + Double.isNaN(nan));
    IO.println("Double.compare(nan, nan) = " + Double.compare(nan, nan)
            + ",  Double.valueOf(nan).equals(nan): " + Double.valueOf(nan).equals(nan));
    IO.println("0.0 == -0.0  : " + (0.0 == -0.0) + ",  Double.compare(0.0, -0.0) = " + Double.compare(0.0, -0.0)
            + ",  1 / -0.0 = " + 1 / -0.0);
    IO.println("MAX_VALUE * 2 = " + Double.MAX_VALUE * 2 + ",  MAX_VALUE + 1 == MAX_VALUE: " + (Double.MAX_VALUE + 1 == Double.MAX_VALUE));
}

from session import run, version

version()
run("""
java Specials.java
""")

# openjdk version "25.0.4.1" LTS
$ java Specials.java
1.0 / 0      = Infinity,  -1.0 / 0 = -Infinity
0.0 / 0.0    = NaN,  Math.sqrt(-1) = NaN
nan == nan   : false,  Double.isNaN(nan): true
Double.compare(nan, nan) = 0,  Double.valueOf(nan).equals(nan): true
0.0 == -0.0  : true,  Double.compare(0.0, -0.0) = 1,  1 / -0.0 = -Infinity
MAX_VALUE * 2 = Infinity,  MAX_VALUE + 1 == MAX_VALUE: true

• 1.0 / 0 is Infinity, while the integer division 1 / 0 throws. Double.MAX_VALUE * 2 overflows to Infinity, and Double.MAX_VALUE + 1 is still Double.MAX_VALUE, because 1 is far smaller than the gap between doubles there.
• 0.0 / 0.0 and Math.sqrt(-1) are NaN. NaN compares false with everything, itself included, so nan == nan is false; test for it with Double.isNaN. Double.compare and Double.valueOf(nan).equals treat NaN as equal to itself, which keeps sorting and hash maps working.
• -0.0 == 0.0 is true, but the two zeros differ: 1 / -0.0 is negative infinity, and Double.compare(0.0, -0.0) is 1. A sort puts -0.0 before 0.0.

The run shows two ways of comparing that disagree on exactly these values. Read the two cases side by side:

== follows IEEE 754, which a sort or a hash map cannot use; Double.compare and equals give every double one place in a single order.

Each way of rounding a double has its own rule

Math.round, Math.rint, Math.floor, Math.ceil, %.2f and a cast to int each turn a double into fewer digits, and no two of them follow the same rule. The program runs them on the same values:

// Ways to round a double, and the one that quietly cuts instead.
void main() {
    IO.println("Math.round(2.5) = " + Math.round(2.5) + ", Math.round(-2.5) = " + Math.round(-2.5));
    IO.println("Math.rint(2.5)  = " + Math.rint(2.5) + ", Math.rint(3.5) = " + Math.rint(3.5));
    IO.println("Math.floor(-2.5) = " + Math.floor(-2.5) + ", Math.ceil(-2.5) = " + Math.ceil(-2.5));
    IO.println("%.2f of 2.675   = " + String.format("%.2f", 2.675));
    IO.println("stored 2.675    = " + new BigDecimal(2.675));
    IO.println("new BigDecimal(2.675), 2 places, HALF_UP     = " + new BigDecimal(2.675).setScale(2, RoundingMode.HALF_UP));
    IO.println("BigDecimal.valueOf(2.675), 2 places, HALF_UP = " + BigDecimal.valueOf(2.675).setScale(2, RoundingMode.HALF_UP));
    IO.println("0.57 * 100 = " + 0.57 * 100 + ", (int) gives " + (int) (0.57 * 100) + ", Math.round gives " + Math.round(0.57 * 100));
}

from session import run, version

version()
run("""
java Rounding.java
""")

# openjdk version "25.0.4.1" LTS
$ java Rounding.java
Math.round(2.5) = 3, Math.round(-2.5) = -2
Math.rint(2.5)  = 2.0, Math.rint(3.5) = 4.0
Math.floor(-2.5) = -3.0, Math.ceil(-2.5) = -2.0
%.2f of 2.675   = 2.68
stored 2.675    = 2.67499999999999982236431605997495353221893310546875
new BigDecimal(2.675), 2 places, HALF_UP     = 2.67
BigDecimal.valueOf(2.675), 2 places, HALF_UP = 2.68
0.57 * 100 = 56.99999999999999, (int) gives 56, Math.round gives 57

• Math.round returns the nearest long and sends a tie upwards, toward positive infinity: Math.round(2.5) is 3 and Math.round(-2.5) is -2.
• Math.rint sends a tie to the even neighbour, so 2.5 becomes 2.0 and 3.5 becomes 4.0. Math.floor rounds down and Math.ceil rounds up.
• String.format("%.2f", 2.675) gives 2.68. Java’s formatter rounds the shortest decimal form of the double, the digits Double.toString prints, with the half-up rule, so it sees “2.675” and rounds up. The exact stored value is a little below 2.675, so rounding that value gives 2.67, which is what new BigDecimal(2.675) does, while BigDecimal.valueOf(2.675) starts from the digits “2.675” and gives 2.68.
• 0.57 * 100 is 56.99999999999999, and a cast to int cuts the fraction off, giving 56. Use Math.round when a floating-point result has to become a whole number.

The third point is the one that surprises people. Step through what each of the three calls reads of 2.675 before it rounds:

BigDecimal keeps decimals exact with a scale and a rounding mode

A BigDecimal stores a whole number of any size, its unscaled value, and a scalescale: The number of digits after the decimal point of a BigDecimal: 19.99 has scale 2. A BigDecimal is its unscaled whole number times 10 to the power minus its scale, so 2.0 and 2.00 have the same value but different scales., the number of digits after the decimal point. The diagram shows both parts for 19.99, 2.0 and 2.00:

Because it counts in powers of 10, every decimal amount you can write is exact. Addition, subtraction and multiplication are always exact; division and rounding need you to say how many digits to keep and which rounding moderounding mode: The rule a BigDecimal follows when it must drop digits, given as a RoundingMode: HALF_UP sends a tie away from zero, HALF_EVEN to the even neighbour, DOWN cuts toward zero, and UNNECESSARY throws if any digit would be lost. to use:

// Decimal arithmetic with BigDecimal: exact sums, an explicit scale and rounding mode for division.
void main() {
    var price = new BigDecimal("19.99");
    IO.println("3 × 19.99          = " + price.multiply(BigDecimal.valueOf(3)));
    IO.println("0.1 + 0.2          = " + new BigDecimal("0.1").add(new BigDecimal("0.2")));
    IO.println("new BigDecimal(0.1) = " + new BigDecimal(0.1));
    IO.println("BigDecimal.valueOf(0.1) = " + BigDecimal.valueOf(0.1));

    var bill = new BigDecimal("100.00");
    try {
        IO.println(bill.divide(BigDecimal.valueOf(3)));
    } catch (ArithmeticException e) {
        IO.println("100.00 / 3: " + e.getMessage());
    }
    var share = bill.divide(BigDecimal.valueOf(3), 2, RoundingMode.DOWN);
    var last = bill.subtract(share.multiply(BigDecimal.valueOf(2)));
    IO.println("three shares: " + share + " + " + share + " + " + last);

    var a = new BigDecimal("2.345");
    IO.println("2.345 HALF_UP " + a.setScale(2, RoundingMode.HALF_UP) + ", HALF_EVEN " + a.setScale(2, RoundingMode.HALF_EVEN)
            + ", DOWN " + a.setScale(2, RoundingMode.DOWN));
}

// equals compares value and scale; compareTo compares value only.
void main() {
    var two = new BigDecimal("2.0");
    var twoAgain = new BigDecimal("2.00");
    IO.println("scales: " + two.scale() + " and " + twoAgain.scale());
    IO.println("equals: " + two.equals(twoAgain) + ", compareTo: " + two.compareTo(twoAgain));
    IO.println("in a HashSet: " + new HashSet<>(List.of(two, twoAgain)).size() + " elements");
    IO.println("in a TreeSet: " + new TreeSet<>(List.of(two, twoAgain)).size() + " element");
    IO.println("after stripTrailingZeros: " + two.stripTrailingZeros().equals(twoAgain.stripTrailingZeros()));
}

from session import run, version

version()
run("""
java Money.java
java Equality.java
""")

# openjdk version "25.0.4.1" LTS
$ java Money.java
3 × 19.99          = 59.97
0.1 + 0.2          = 0.3
new BigDecimal(0.1) = 0.1000000000000000055511151231257827021181583404541015625
BigDecimal.valueOf(0.1) = 0.1
100.00 / 3: Non-terminating decimal expansion; no exact representable decimal result.
three shares: 33.33 + 33.33 + 33.34
2.345 HALF_UP 2.35, HALF_EVEN 2.34, DOWN 2.34
$ java Equality.java
scales: 1 and 2
equals: false, compareTo: 0
in a HashSet: 2 elements
in a TreeSet: 1 element
after stripTrailingZeros: true

• Build a BigDecimal from a string, new BigDecimal("19.99"), or from a whole number. new BigDecimal(0.1) copies the double exactly, error and all; BigDecimal.valueOf(0.1) goes through Double.toString and gives 0.1.
• Divide with a scale and a rounding mode. bill.divide(three) throws, because 100.00 / 3 has no finite decimal form. divide(three, 2, RoundingMode.DOWN) gives 33.33, and the last share takes what is left, 33.34, so the three shares add up to the bill.
• Choose the rounding mode on purpose. HALF_UP is the school rule; HALF_EVEN, sometimes called banker’s rounding, sends ties to the even neighbour, so that rounding many values does not drift upwards; DOWN cuts. The rule for an invoice or a tax comes from the business or the law, so check which one applies.
• equals compares the scale too. 2.0 has scale 1 and 2.00 scale 2, so equals says they differ, while compareTo compares values and returns 0. A HashSet, which uses equals, keeps both; a TreeSet, which uses compareTo, keeps one. Compare amounts with compareTo, or bring them to one scale first.

The table puts the three ways of storing an amount side by side:

A tax must be what is left of the price

A price that includes a sales tax, VAT or GST has to be split into the price before tax and the tax itself. It is tempting to compute both parts and round each one. The run below does that at a rate of 12 % for every price from 0.01 to 1,000.00:

// Rounding the base and the tax separately: how often do they still add up to the price?
void main() {
    var hundred = BigDecimal.valueOf(100);
    var rate = BigDecimal.valueOf(12);
    var divisor = hundred.add(rate);
    int wrong = 0;
    BigDecimal first = null;
    for (int cents = 1; cents <= 100_000; cents++) {
        var price = BigDecimal.valueOf(cents, 2);
        var base = price.multiply(hundred).divide(divisor, 2, RoundingMode.HALF_UP);
        var tax = price.multiply(rate).divide(divisor, 2, RoundingMode.HALF_UP);
        if (base.add(tax).compareTo(price) != 0) {
            wrong++;
            if (first == null) first = price;
        }
    }
    IO.println(wrong + " of 100000 prices from 0.01 to 1000.00 do not add up at 12 %");
    var base = first.multiply(hundred).divide(divisor, 2, RoundingMode.HALF_UP);
    var tax = first.multiply(rate).divide(divisor, 2, RoundingMode.HALF_UP);
    IO.println("the first is " + first + ": base " + base + " + tax " + tax + " = " + base.add(tax));
    var exactBase = first.multiply(hundred).divide(divisor, MathContext.DECIMAL64);
    var exactTax = first.multiply(rate).divide(divisor, MathContext.DECIMAL64);
    IO.println("its exact parts: base " + exactBase + " + tax " + exactTax);
}

from session import run, version

version()
run("""
java NaiveSplit.java
""")

# openjdk version "25.0.4.1" LTS
$ java NaiveSplit.java
3571 of 100000 prices from 0.01 to 1000.00 do not add up at 12 %
the first is 0.14: base 0.13 + tax 0.02 = 0.15
its exact parts: base 0.125 + tax 0.015

For 3,571 of the 100,000 prices, the two rounded parts do not add up to the price, the first already at 0.14. Step through that first price, from its exact parts to the cent that appears from nowhere:

The fix is to round one part and make the other what is left, which the exercise below asks you to write.

Practise: split a tax-inclusive price

Write split(inclusive, ratePercent), which returns the price before tax and the tax, both with two decimal places. Round the base with RoundingMode.HALF_UP, then make the tax whatever is left, so that the two always add up to the price. The last check tries every price from 0.01 to 1,000.00 at 12 %:

// Exercise: split(inclusive, ratePercent) splits a price that includes a sales tax (VAT or GST) into the price
// before tax and the tax, both with 2 decimal places. Round the base with HALF_UP, then make the tax what is left,
// so that base + tax is always exactly the price. Write it, then run this file: every check must say ok.
record Split(BigDecimal base, BigDecimal tax) {}

Split split(BigDecimal inclusive, int ratePercent) {
    return new Split(BigDecimal.ZERO, BigDecimal.ZERO);   // replace this line
}

int failures = 0;

void check(String price, int rate, String base, String tax) {
    Split s = split(new BigDecimal(price), rate);
    boolean passed = s.base().equals(new BigDecimal(base)) && s.tax().equals(new BigDecimal(tax));
    if (!passed) failures++;
    IO.println((passed ? "ok      " : "FAILED  ") + price + " at " + rate + " %: " + s.base() + " + " + s.tax());
}

void main() {
    check("118.00", 18, "100.00", "18.00");
    check("99.99", 18, "84.74", "15.25");
    check("1000.00", 5, "952.38", "47.62");
    check("100", 18, "84.75", "15.25");
    check("59.00", 0, "59.00", "0.00");
    check("0.00", 18, "0.00", "0.00");
    check("-118.00", 18, "-100.00", "-18.00");
    int bad = 0;
    for (int cents = 1; cents <= 100_000; cents++) {
        var price = BigDecimal.valueOf(cents, 2);
        Split s = split(price, 12);
        if (s.base().add(s.tax()).compareTo(price) != 0) bad++;
    }
    if (bad > 0) failures++;
    IO.println((bad == 0 ? "ok      " : "FAILED  ") + "base + tax is the price for every price from 0.01 to 1000.00 (" + bad + " wrong)");
    IO.println(failures + " of 8 checks failed");
    if (failures > 0) System.exit(1);
}

As given, the method returns two zeros:

from session import run, version

version()
run("""
!java TaxSplit.java
""")

# openjdk version "25.0.4.1" LTS
$ java TaxSplit.java
FAILED  118.00 at 18 %: 0 + 0
FAILED  99.99 at 18 %: 0 + 0
FAILED  1000.00 at 5 %: 0 + 0
FAILED  100 at 18 %: 0 + 0
FAILED  59.00 at 0 %: 0 + 0
FAILED  0.00 at 18 %: 0 + 0
FAILED  -118.00 at 18 %: 0 + 0
FAILED  base + tax is the price for every price from 0.01 to 1000.00 (100000 wrong)
8 of 8 checks failed
[exit status 1]

First hint: the base is inclusive × 100 / (100 + rate), and divide(divisor, 2, RoundingMode.HALF_UP) gives it two decimal places. The checks compare both parts with equals, which looks at the scale too, and inclusive.subtract(base) keeps the base’s two places: even a price written as “100” gives the tax 15.25.

With all eight checks at ok, practise the seven ideas of this lesson, from stored values to the tax split. Questions you miss come back before the end, and each one explains its answer as soon as you check it:

Interview questions

Fresher · Why should money not be stored in a double?

A double is a binary fraction, so most decimal amounts, such as 0.10 or 19.99, are stored as the nearest binary value rather than exactly, and each operation rounds again. Totals then miss by tiny amounts, such as 0.30000000000000004, comparisons with == fail, and rounding for display can give a different cent from the one an invoice rule expects. Use BigDecimal, built from strings, with an explicit scale and RoundingMode, or a long that counts the smallest unit, such as cents. Keep double for measurements, where a tiny relative error does not matter.

Key takeaways

• A double is an IEEE 754 binary64 number; most decimal fractions are stored as the nearest binary value, so 0.1 + 0.2 is 0.30000000000000004.
• Since JDK 17 floating-point arithmetic gives identical results everywhere and strictfp does nothing; since JDK 19 Double.toString prints the shortest decimal that identifies the double.
• Compare computed doubles with a tolerance, relative plus absolute near zero; test NaN with Double.isNaN, and remember that == and Double.compare disagree on NaN and on -0.0.
• Math.round sends ties up, Math.rint to even; %.2f rounds the printed decimal digits half up; a cast to int cuts the fraction off.
• Use BigDecimal for money: build it from strings, divide with a scale and a RoundingMode, compare with compareTo, because equals also compares the scale.
• When a total is split, round one part and make the other what is left, so the parts always add up.