Considering the behavior of BigDecimal(double)
is correct, in my opinion, I'm not too sure it really would be such a problem.
I wouldn't exactly agree with the wording of the documentation in the BigDecimal(double)
constructor:
The results of this constructor can be
somewhat unpredictable. One might
assume that writing new
BigDecimal(0.1)
in Java creates a
BigDecimal
which is exactly equal to
0.1
(an unscaled value of 1
, with a scale of 1
), but it is actually equal
to
0.1000000000000000055511151231257827021181583404541015625
.
(Emphasis added.)
Rather than saying unpredictable, I think the wording should be unexpected, and even so, this would be unexpected behavior for those who are not aware of the limitations of representation of decimal numbers with floating point values.
As long as one keeps in mind that floating point values cannot represent all decimal values with precision, the value returned by using BigDecimal(0.1)
being 0.1000000000000000055511151231257827021181583404541015625
actually makes sense.
If the BigDecimal
object instantiated by the BigDecimal(double)
constructor is consistent, then I would argue that the result is predictable.
My guess as to why the BigDecimal(double)
constructor is not being deprecated is because the behavior can be considered correct, and as long as one knows how floating point representations work, the behavior of the constructor is not too surprising.