The "problem" in this bug is that the code is using the BigDecimal double construtor instead of the BigDecimal string constructor. The exact value of a decimal floating-point literal (like "0.115") generally cannot be stored in a floating-point number since floating-point numbers use base 2 instead of base 10. Instead of the exact value of the literal, you get a value that is very close; for the values in question:
0.115d is exactly 0.11500000000000000499600361081320443190634250640869140625
1.115d is exactly 1.1149999999999999911182158029987476766109466552734375
2.115d is exactly 2.1150000000000002131628207280300557613372802734375
These exact double values are then converted to BigDecimal (all finite binary floating-point values can be exactly represented as BigDecimals) as described in the BigDecimal class documetnation. Now, it is easy to see why the given output was observed; using the string constructor gives the "expected" results.
This issue is explicitly discussed in the BigDecimal documentation for the double constructor:
"Translates a double into a BigDecimal. The scale of the BigDecimal is the smallest value such that (10scale * val) is an integer.
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances nonwithstanding.
The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one. "
See "What Everybody Using the JavaTM Programming Language Should Know About Floating-Point Arithmetic"
for further discussion of Java numerics issues.
Closing as not a bug.