RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals

[Bruce Chapman]

Stephen, In your case(s) would the workaround fail to work if the bug 
was fixed?

Working around a bug is quite different to taking advantage of the buggy 
behaviour.  If fixing the bug would break code that works around it that 
can be seen as a problem, while breaking code that relies on the bug is 
IMHO much less of an issue since anyone that does that is taking a known 
risk, or a risk that should reasonably be expected to be known.

I am finding it hard to imagine a genuine attempt at a workaround that 
would not still work (though redundantly) if the bug was fixed.

Also bear in mind that there are other implementations, and the 
signature and the javadoc are the spec. If you find behaviour that 
differs and take advantage of that behaviour then you are opening the 
possibility of it changing if either: you run with another 
implementation, or the bug gets fixed.

While it is easy to contrive an example that would break if this bug 
were fixed, and it is possible (on the grounds that I cannot prove it is 
impossible) that some real code might break, it is hard to imagine a 
scenario where the author/owner of that broken code has any morally 
legitimate grounds for complaint in that case.

I guess if you take the "This is one of those unfortunate cases where a 
bug can become a feature." approach to its logical conclusion then no 
bugs get fixed because there are no bugs, just a nice online list of 
newly discovered unexpected features.

Bruce

On 7/02/2013 12:16 p.m., Stephen Colebourne wrote:
> On 5 February 2013 09:09, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> This is one of those unfortunate cases where a bug can become a feature.
> I *really* don't see how.
>
> The method name is absolutely clear about its purpose. "Strip trailing
> zeros". Anyone relying on it not stripping zeroes for zero needs their
> head examining.
>
> This particular one just happens to be one that I've run across twice
> and in both cases it required a workaround. I'd argue that there are
> more people with undiscovered bugs in their code because the method is
> buggy than people who would break were the method fixed.
>
> What bothers me even more is the desire expressed in this thread to
> simply wish away bugs by redefining the documentation. If the method
> name is clear enough, like in this case, then its a bug, and a
> documentation change simply isn't the right solution.
> Stephen
>