Why is the Bigdecimal(double d) construction still around?

Question

I've noticed substantial pain over this constructor (even here on Stack Overflow). People use it even though the documentation clearly states:

The results of this constructor can be somewhat unpredictable http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double)

I've even seen a JSR-13 being APPROVED with a recommendation stating:

Existing specifications that might be deprecated: We propose deprecating the BigDecimal(double) constructor, which currently gives results that are different to the Double.toString() method.

Despite all this, the constructor has not yet been deprecated.

I'd love to hear any views on this.

score 20 · Answer 1 · answered Jun 29 '09 at 11:54

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.

Great arguments! ">as long as one knows how floating point representations work" ... guess this sentence eliminates ~95% of the programming world (probably more). Preventing those 95% of programmers causing millions(?) of dollars in accounting errors might probably be what prompted that recommendation in JSR-13 :) — Ryan Fernandes, Jun 30 '09 at 05:53
following that reasoning (not only) double and float must be removed ASAP — user85421, Jul 21 '09 at 11:17
It's important for computer scientists to remember that not all floating point values can be represented, but I don't think that means that this constructor is good. While some floating point values can't be represented by a double, IMO there should be no reason that the ones that can would be misrepresented when using the double constructor. In fact, it's even worse that other documentation within this class hints at the constructor's weakness http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#valueOf(double) — butallmj, Oct 04 '13 at 19:18

score 3 · Accepted Answer · answered Jun 29 '09 at 12:17

3

Deprecation is deprecated. Parts of APIs are only marked deprecated in exceptional cases.

So, run FindBugs as part of your build process. FindBugs has a detector PlugIn API and is also open source (LGPL, IIRC).

answered Jun 29 '09 at 12:17

Tom Hawtin - tackline

145,806
30
211
305

.. And after long consideration I feel that is the only possible answer - A policy from the Keepers of the API. Nothing else could completely explain this. – Ryan Fernandes Jul 01 '09 at 03:25
3

Why is deprecation deprecated? I have just found http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html and it doesn't say anything about that. – siledh Jan 08 '14 at 13:32

score 1 · Answer 3 · edited Nov 04 '11 at 13:27

1

That particular constructor, like all floating point operations, is an approximation. It's not really broken, it just has shortcomings.
Just do your research, approach it with care, and you won't get any surprises. You run into exactly the same thing when assigning decimal literals to doubles/floats.

edited Nov 04 '11 at 13:27

mskfisher

3,291
4
35
48

answered Jun 29 '09 at 05:54

mP.

18,002
10
71
105

2

Good point, it is like a landmine for unsuspecting developers. Landmines never served anyone in the long run.. which is why the JSR I guess... – Ryan Fernandes Jun 29 '09 at 05:59

Why is the Bigdecimal(double d) construction still around?

3 Answers3

Linked