RFR - 6480539: BigDecimal.stripTrailingZeros() should specify no-op on zero BigDecimals
joe.darcy at oracle.com
Fri Feb 15 05:54:18 UTC 2013
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.
> 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
> Mostly the JDK team gets it right. But not this time.
>> On 8 Feb 2013 20:32, "Joe Darcy" <joe.darcy at oracle.com> wrote:
>>> 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:
>>> 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.
>>>> 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
>>>>> 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.
More information about the core-libs-dev