RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals
Stephen Colebourne
scolebourne at joda.org
Mon Feb 4 18:13:49 UTC 2013
On 4 February 2013 18:09, Brian Burkhalter <brian.burkhalter at 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
More information about the core-libs-dev
mailing list