Thanks for continuing to look at this with Brian I also had this response on twitter - "my most hated Java bug, top 1" https://twitter.com/temerev/status/300204751931453440
Stephen On 15 February 2013 05:54, Joe Darcy <joe.da...@oracle.com> wrote: > 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.da...@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.san...@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 >>>>>> >
