Почему строительство Bigdecimal (double d) по-прежнему существует?

Я заметил существенную боль над этим конструктором (даже здесь, в Stack Overflow). Люди используют его, хотя в документации четко указано:

Результаты этого конструктора могут быть несколько непредсказуемыми http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double)

Я даже видел JSR-13 APPROVED с рекомендацией:

Существующие спецификации, которые могут быть устаревшими: мы предлагаем отказаться от конструктора BigDecimal (double), который в настоящее время дает результаты, отличные от метода Double.toString().

Несмотря на это, конструктор еще не устарел.

Мне бы хотелось услышать любые мнения по этому поводу.

Ответ 1

Устаревание устарело. Части API-интерфейсов отмечены только в исключительных случаях.

Итак, запустите FindBugs как часть процесса сборки. У FindBugs есть API-интерфейс PlugIn API, а также открытый источник (LGPL, IIRC).

Ответ 2

Учитывая поведение BigDecimal(double), на мой взгляд, я не уверен, что это действительно будет такой проблемой.

Я бы точно не согласился с формулировкой документации в конструкторе BigDecimal(double):

Результаты этого конструктора могут быть несколько непредсказуемый. Можно было бы предположим, что запись new BigDecimal(0.1) в Java создает BigDecimal, который в точности равен 0.1 (немасштабированное значение 1 со шкалой 1), но на самом деле оно равно в 0.1000000000000000055511151231257827021181583404541015625.

(Акцент добавлен.)

Вместо того, чтобы говорить непредсказуемо, я думаю, что формулировка должна быть неожиданной, и даже в этом случае это было бы неожиданным поведением для тех, кто не знает ограничений представления десятичных чисел с значения с плавающей запятой.

До тех пор, пока вы помните, что значения с плавающей запятой не могут представлять все десятичные значения с точностью, значение, возвращаемое с помощью BigDecimal(0.1), являющееся 0.1000000000000000055511151231257827021181583404541015625, действительно имеет смысл.

Если объект BigDecimal, созданный конструктором BigDecimal(double), согласован, тогда я бы сказал, что результат предсказуем.

Мое предположение о том, почему конструктор BigDecimal(double) не устаревает, состоит в том, что поведение можно считать правильным, и пока кто-то знает, как работают представления с плавающей запятой, поведение конструктора не слишком удивительно.

Ответ 3

Этот конкретный конструктор, как и все операции с плавающей запятой, является приближением. Это действительно не сломано, у него просто недостатки.
Просто делайте свое исследование, подходите к нему с осторожностью, и вы не получите никаких сюрпризов. Вы сталкиваетесь точно так же, когда приписываете десятичные литералы удваивать/плавать.