DecimalFormat с использованием неправильного RoundingMode, даже если он установлен явно

(Ответ ниже с использованием Java 8.)

Проблема, которую вы видите, возникает из-за указания в коде «0,15» или «0,05», что при представлении в виде двойного числа составляет чуть меньше 0,15. Проверь это

DecimalFormat df = new DecimalFormat("#.#");

df.setRoundingMode(RoundingMode.HALF_UP);

BigDecimal bd = new BigDecimal(0.15);
System.out.println("bd=" + bd);
System.out.println(df.format(0.15)); // expecting 0.1, getting 0.1
bd = new BigDecimal(0.05);
System.out.println("bd=" + bd);
System.out.println(df.format(0.05));
bd = new BigDecimal(0.06);
System.out.println("bd=" + bd);
System.out.println(df.format(0.06));

Вывод этого кода

bd=0.1499999999999999944488848768742172978818416595458984375
0.1
bd=0.05000000000000000277555756156289135105907917022705078125
0.1
bd=0.059999999999999997779553950749686919152736663818359375
0.1

Возможное решение (если вам абсолютно необходимо округлить его правильно) — использовать BigDecimal.valueOf для создания значения. Например

BigDecimal bd = BigDecimal.valueOf(0.15);
System.out.println("bd=" + bd);
System.out.println(df.format(bd)); // expecting 0.1, getting 0.1
bd = BigDecimal.valueOf(0.05);
System.out.println("bd=" + bd);
System.out.println(df.format(bd));
bd = BigDecimal.valueOf(0.06);
System.out.println("bd=" + bd);
System.out.println(df.format(bd));

Теперь будет уступать

bd=0.15
0.2
bd=0.05
0.1
bd=0.06
0.1

Кстати, как указал Scary Wombat, маска, установленная как 0,0 вместо #.#, сделает 0,6 0. Но я думаю, что это было более позднее редактирование, чем когда я начал смотреть на это. Использовать #.#.

Когда вы делаете

df.format(0.15);

на самом деле две операции округления. Очевидным является тот, который вы просили с df.format, но есть более ранний, который происходит во время компиляции.

Десятичное значение 0,15 не может быть представлено как двойное. Двойники могут представлять только рациональные числа, знаменатель которых является степенью двойки, точно так же, как десятичная запись может представлять только рациональные числа, знаменатель которых является степенью числа десять. Когда вы пишете 0.15, компилятор округляет это значение до ближайшего значения, которое может быть представлено как двойное, и это значение оказывается равным

0.1499999999999999944488848768742172978818416595458984375

который df.format правильно округляется. Это не совсем середина между 0,1 и 0,2, поэтому режим округления HALF_UP не имеет значения.

Что касается

df.format(0.06); // expecting 0.1, getting 0.0  << unexpected

Если вы видите это, это ошибка. Похоже, он соответствует ссылке ScaryWombat, исправленной в 8u40 и 8у45. Тест на Ideone, который использует 8u51, показывает правильное поведение. Обновление Java должно решить проблему.

Я думаю, что ответом является Стандарт IEEE для арифметики с плавающей запятой (IEEE 754). В статье Wiki есть хороший пример в разделе правил округления. Также вы можете прочитать раздел 9.1 Введения в Java, в котором больше рассказывается о плавающей запятой. BigDecimal устраняет большинство этих недостатков, сохраняя значение внутри BigInteger, точность и масштаб в отдельных целочисленных полях.