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

[Bruce Chapman]

I didn't know that Randall was following this mailing list and this thread.

http://xkcd.com/1172/

Bruce


On 9/02/2013 9:32 a.m., Joe Darcy wrote:
> 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
>>>
>>
>
>