On 4 February 2013 18:09, Brian Burkhalter <brian.burkhal...@oracle.com> wrote:
> While stripTrailingZeros() should perhaps for purity of specification always
> return BigDecimal.ZERO for anything which is numerically equal to zero, the
> present behavior of this method has been extant for some years, so following
> the prevailing convention it would be preferable to modify the specification
> to match the behavior.
>
> Proposed change:
>
> diff -r 20eeb727d171 -r 8789e8736763
> src/share/classes/java/math/BigDecimal.java
> --- a/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53
> 2013 -0800
> +++ b/src/share/classes/java/math/BigDecimal.java Fri Feb 01 16:32:53
> 2013 -0800
> @@ -2589,7 +2589,9 @@
> * the {@code BigDecimal} value {@code 600.0}, which has
> * [{@code BigInteger}, {@code scale}] components equals to
> * [6000, 1], yields {@code 6E2} with [{@code BigInteger},
> - * {@code scale}] components equals to [6, -2]
> + * {@code scale}] components equals to [6, -2]. This method has no
> + * effect on a {@code BigDecimal} <i>x</i> which is numerically
> + * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}.
> *
> * @return a numerically equal {@code BigDecimal} with any
> * trailing zeros removed.
This is a bug that has bitten me on more than one occasion. Changing
the spec is not the solution here. Fixing the bug is.
Stephen
