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

[Joe Darcy]

On 02/08/2013 02:37 PM, Stephen Colebourne wrote:
> We've established that it causes problems (me and Paul) and that likely
> workarounds of the bug would not be broken by a fix.

The adaptation you and Paul have for the current behavior would not be 
impacted by a change in the behavior of stringTrailingZeros. That just 
leaves all the other Java programmers to check with ;-)

Since any angry emails on changing the behavior would come the way of 
Brian and I (probably in a few years time), Brian has agreed to do some 
additional research on how stripTrailingZeros is used in existing code 
to gauge what impact there could be to altering the long-standing 
behavior. If the impact is small, we can make the change in JDK 8.

-Joe


>
> The getMethods case is very different as the spec clearly allowed the
> behavior. Here the spec and method name are also clear on the expected
> behavior. The proposal would make the behavior out of line with the method
> name and of no earthly use to users. ie, as a user of that method, I would
> never be calling it for any reason other than to remove all the trailing
> zeroes.
>
> Mostly the JDK team gets it right. But not this time.
>
> Stephen
>
>> On 8 Feb 2013 20:32, "Joe Darcy" <joe.darcy at oracle.com> 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
>>>>>