By Neil Chaudhuri | November 6, 2014
Experienced Java developers know that Java 5 brought many significant improvements to the language.
One of them was the introduction of BigDecimal, an
abstraction for arbitrary-precision decimal numbers that gives you arithmetic functionality and complete control over
rounding and scale. All of this flexibility and power made
BigDecimal the de facto class Java developers used to model money–at
least until Java 7 gave us the Currency class.
On a recent project though with an API that doesn’t use
Currency, I had a simple question:
How do you test if a BigDecimal is 0?
It turns out that the power of
BigDecimal makes this question a lot trickier than you might think.
We do this kind of thing all the time without a second thought. The problem was that my unit test failed, and it turns
out it was because the condition always evaluated to
price was definitely 0.
It turns out zero isn’t always zero. At least not when it comes to
The answer is in
BigDecimal’s implementation of the equals
Unlike compareTo, this method considers two BigDecimal objects equal only if they are equal in value and scale (thus 2.0 is not equal to 2.00 when compared by this method).
equals just compared values, but scale matters.
BigDecimal.ZERO has scale of 0, but the zero value in
price in my test did not.
That’s why things went wrong.
What’s the right way to check if your BigDecimal instance is 0? It turns out there are two right ways.
This approach is intuitive and readable.
If you want to sacrifice readability to gain a few milliseconds of performance and earn some cuteness points, you can do this.
BigDecimal, like all values in Java, represents a signed number, and the signum
method returns the sign of the underlying number. Technically,
test the numerical value, but since a BigDecimal representing 0 always has a signum of 0…it works out the same in your condition.
The next time you are checking if your BigDecimal is 0, just remember. It depends on what the meaning of the word of is is.