私はこのコンストラクターにかなりの苦痛があることに気づきました（ここでもStack Overflowで）。ドキュメントに次のように明記されていても、人々はそれを使用します。
このコンストラクターの結果は、多少予測できない場合があります http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double）
JSR-13が承認され、次のような推奨事項が承認されているのを見たこともあります。
非推奨になる可能性のある既存の仕様：BigDecimal（double）コンストラクターの非推奨を提案します。これにより、現在、Double.toString（）メソッドとは異なる結果が得られます。
これらすべてにもかかわらず、コンストラクターはまだ非推奨ではありません。
これについての意見を聞きたいです。
の振る舞いBigDecimal(double)が正しいことを考えると、私の意見では、それが本当にそのような問題になるかどうかはわかりません。
BigDecimal(double)コンストラクターのドキュメントの文言に正確には同意しません。
このコンストラクターの結果は、多少予測できない場合があります。
new BigDecimal(0.1)Java で書くと、 （のスケールなしの値、スケールは）にBigDecimal正確に等しいが 作成されると思われるかもしれませんが、実際には。に等しくなり ます。0.1110.1000000000000000055511151231257827021181583404541015625
（強調が追加されました。）
予測できないと言うのではなく、予期しない表現にする必要があると思います。それでも、浮動小数点値を使用した10進数の表現の制限を認識していない人にとっては、これは予期しない動作になります。
浮動小数点値がすべての10進値を正確に表すことができないことを覚えている限り、BigDecimal(0.1)beingを使用して返される値は0.1000000000000000055511151231257827021181583404541015625実際には意味があります。
コンストラクターによってインスタンス化されたBigDecimalオブジェクトBigDecimal(double)に一貫性がある場合、結果は予測可能であると私は主張します。
コンストラクターが非推奨にならない理由についての私の推測BigDecimal(double)は、動作が正しいと見なすことができるためです。浮動小数点表現がどのように機能するかを知っている限り、コンストラクターの動作はそれほど驚くべきものではありません。
非推奨は非推奨です。APIの一部は、例外的な場合にのみ非推奨としてマークされます。
したがって、ビルドプロセスの一部としてFindBugsを実行します。FindBugsには検出器プラグインAPIがあり、オープンソース（LGPL、IIRC）でもあります。
その特定のコンストラクターは、すべての浮動小数点演算と同様に近似値です。それは本当に壊れているわけではなく、欠点があるだけです。
調査を行い、注意してアプローチすれば、驚きはありません。double/float に 10 進リテラルを代入するときに、まったく同じことが起こります。