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

[Joe Darcy]

Hello,

On 2/6/2013 11:32 PM, Bruce Chapman wrote:
> 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.

As noted earlier in this thread, we use a nuanced compatibility policy 
in evolving the JDK:

http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html

In particular, besides looking after source and binary compatibility, we 
also look to manage behavioral compatibility, that is, to be mindful of 
changing what a method does at runtime when called, even when the 
specification gives us leeway to do so.

Let me relate an example of behavioral compatibility from JDK 7. The 
method Class.getMethods returns an array of Method objects for the Class 
and in part its javadoc has long stated:

     "The elements in the array returned are not sorted and are not in 
any particular order."

Therefore, any caller of Class.getMethods relying on or assuming a 
particular order has a bug according to the specification.  As a 
side-effect of permgen removal in JDK 7, the long-standing (and mostly 
stable) order of Method objects returned by HotSpot changed. As 
expected, some user applications and tests "broke" after this change 
went in.  We received requests to "fix" the ordering of 
Class.getMethods, which we declined to do given the benefits of permgen 
removal and the clear specification that no ordering should be relied 
upon.  Even though that change in getMethods is allowed by 
specification, it is out-of-bounds of what we would do an an update 
release but in-bounds for a platform release like JDK 7.

The reason for this conservatism is because we value keeping the broad 
usage of the JDK working :-)

Getting back to BigDecimal.stripTrailingZeros, we cannot inspect all 
usages of this method today, nor can we inspect all the future usages of 
BigDecimal.stripTrailingZeros that will be around before JDK 8 is 
adopted for the code in question. We know not everyone migrates to a new 
JDK release promptly; within the past two years I fielded a 
query/complaint about the behavior change in BigDecimal.toString made 
between 1.4.2 and JDK 5 and later.

For these sorts of reasons, the default resolution when the 
specification and implementation conflict is to make the specification 
match the implementation.  There are exceptions to this default. Given 
sufficient evidence that changing the behavior of 
BigDecimal.stripTrailingZeros would not have adverse consequences on 
fielded code, we could change its behavior despite being implemented 
that way for about 9 years.

-Joe

>
> 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
>>
>