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

[Stephen Colebourne]

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 

Re: 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.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

Re: 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.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 

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

[Brian Burkhalter]

:-)

On Feb 12, 2013, at 12:19 AM, Bruce Chapman wrote:

 I didn't know that Randall was following this mailing list and this thread.
 
 http://xkcd.com/1172/

Re: 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.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

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

[Stephen Colebourne]

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

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

[Stephen Colebourne]

On 7 February 2013 07:32, Bruce Chapman brucechap...@paradise.net.nz wrote:
 Stephen, In your case(s) would the workaround fail to work if the bug was
 fixed?

No. The workaround would handle the fixed implementation just fine.
And all workarounds would ultimately be similar to mine.
https://github.com/OpenGamma/OG-Platform/blob/master/projects/OG-Util/src/main/java/com/opengamma/util/JdkUtils.java#L26

 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.

Thats the underlying part of the issue here that concerns me.

Stephen

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

[Paul Benedict]

I am chiming in to agree with Stephen. About a year ago, I encountered the
same issue and was extremely dissatisfied with the behavior. I was forced
to create a utility method to check for 0 before passing it onto
stripTrailingZeros(). The current behavior is useless; the spec is clear
stripping extra zeros means exactly that.

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

[Stephen Colebourne]

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

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

[Bruce Chapman]

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.


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

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

[Paul Sandoz]

On Feb 5, 2013, at 1:05 AM, Joseph Darcy joe.da...@oracle.com wrote:
 
 On 2/4/2013 1:36 PM, Stephen Colebourne wrote:
 On 4 February 2013 19:31, Joe Darcy joe.da...@oracle.com wrote:
 The stripTrailingZeros method has acted in this surprising way since the
 IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped
 in 2004.
 
 This situation is analogous to when the specification and behavior disagree.
 Our general policy to resolve such cases when evolving the JDK is:
 
 ..., there are times in evolving the JDK when differences are found between
 the specified behavior and the actual behavior (for example 4707389,
 6365176). The two basic approaches to fixing these bugs are to change the
 implementation to match the specified behavior or to change the
 specification (in a platform release) to match the implementation's (perhaps
 long-standing) behavior; often the latter option is chosen since it has a
 lower de facto impact on behavioral compatibility.
 http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html
 
 If this issue were being addressed before JDK 5 shipped or even during JDK
 6, I would support changing the behavior of stripTrailingZeros.  However,
 for addressing this in JDK 8, I think it is more appropriate to keep the
 behavior as-is and document this special case.
 I don't see what JDK 5 vs 6 vs 8 really has to do with it.
 
 The longer a particular behavior has been in a shipped JDK release, the more 
 likely it is various people have built code that depend on that behavior.
 

This is one of those unfortunate cases where a bug can become a feature.

Sometimes it is useful when evaluating to obtain empirical data on how much 
such a feature is used e.g. analysing jars from public maven repos:

http://grepcode.com/search/usages?type=methodid=repository.grepcode.com%24java%24root@jdk%24openjdk@7-b147@java%24math@BigDecimal@stripTrailingZeros%28%29k=u

Of course i have no idea of the internals of BigDecimal and what knock on 
effects such a change would have.

Paul.

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

[Brian Burkhalter]

Hi,

While stripTrailingZeros() should perhaps for purity of specification always 
return BigDecimal.ZERO for anything which is numerically equal to zero, the 
present behavior of this method has been extant for some years, so following 
the prevailing convention it would be preferable to modify the specification to 
match the behavior.

Proposed change:

diff -r 20eeb727d171 -r 8789e8736763 src/share/classes/java/math/BigDecimal.java
--- a/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
2013 -0800
+++ b/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
2013 -0800
@@ -2589,7 +2589,9 @@
  * the {@code BigDecimal} value {@code 600.0}, which has
  * [{@code BigInteger}, {@code scale}] components equals to
  * [6000, 1], yields {@code 6E2} with [{@code BigInteger},
- * {@code scale}] components equals to [6, -2]
+ * {@code scale}] components equals to [6, -2]. This method has no
+ * effect on a {@code BigDecimal} ix/i which is numerically
+ * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}. 
  *
  * @return a numerically equal {@code BigDecimal} with any
  * trailing zeros removed.

Thanks,

Brian

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

[Stephen Colebourne]

On 4 February 2013 18:09, Brian Burkhalter brian.burkhal...@oracle.com wrote:
 While stripTrailingZeros() should perhaps for purity of specification always 
 return BigDecimal.ZERO for anything which is numerically equal to zero, the 
 present behavior of this method has been extant for some years, so following 
 the prevailing convention it would be preferable to modify the specification 
 to match the behavior.

 Proposed change:

 diff -r 20eeb727d171 -r 8789e8736763 
 src/share/classes/java/math/BigDecimal.java
 --- a/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
 2013 -0800
 +++ b/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
 2013 -0800
 @@ -2589,7 +2589,9 @@
   * the {@code BigDecimal} value {@code 600.0}, which has
   * [{@code BigInteger}, {@code scale}] components equals to
   * [6000, 1], yields {@code 6E2} with [{@code BigInteger},
 - * {@code scale}] components equals to [6, -2]
 + * {@code scale}] components equals to [6, -2]. This method has no
 + * effect on a {@code BigDecimal} ix/i which is numerically
 + * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}.
   *
   * @return a numerically equal {@code BigDecimal} with any
   * trailing zeros removed.

This is a bug that has bitten me on more than one occasion. Changing
the spec is not the solution here. Fixing the bug is.
Stephen

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

[Joe Darcy]

On 2/4/2013 10:13 AM, Stephen Colebourne wrote:

On 4 February 2013 18:09, Brian Burkhalter brian.burkhal...@oracle.com wrote:

While stripTrailingZeros() should perhaps for purity of specification always 
return BigDecimal.ZERO for anything which is numerically equal to zero, the 
present behavior of this method has been extant for some years, so following 
the prevailing convention it would be preferable to modify the specification to 
match the behavior.

Proposed change:

diff -r 20eeb727d171 -r 8789e8736763 src/share/classes/java/math/BigDecimal.java
--- a/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
2013 -0800
+++ b/src/share/classes/java/math/BigDecimal.java   Fri Feb 01 16:32:53 
2013 -0800
@@ -2589,7 +2589,9 @@
   * the {@code BigDecimal} value {@code 600.0}, which has
   * [{@code BigInteger}, {@code scale}] components equals to
   * [6000, 1], yields {@code 6E2} with [{@code BigInteger},
- * {@code scale}] components equals to [6, -2]
+ * {@code scale}] components equals to [6, -2]. This method has no
+ * effect on a {@code BigDecimal} ix/i which is numerically
+ * equal to zero, i.e., {@code x.compareTo(BigDecimal.ZERO) == 0}.
   *
   * @return a numerically equal {@code BigDecimal} with any
   * trailing zeros removed.

This is a bug that has bitten me on more than one occasion. Changing
the spec is not the solution here. Fixing the bug is.
Stephen


The stripTrailingZeros method has acted in this surprising way since the 
IBM-led JSR 13 was integrated into the platform back in JDK 5, which 
shipped in 2004.


This situation is analogous to when the specification and behavior 
disagree.  Our general policy to resolve such cases when evolving the 
JDK is:


..., there are times in evolving the JDK when differences are found 
between the specified behavior and the actual behavior (for example 
4707389, 6365176). The two basic approaches to fixing these bugs are to 
change the implementation to match the specified behavior or to change 
the specification (in a platform release) to match the implementation's 
(perhaps long-standing) behavior; often the latter option is chosen 
since it has a lower de facto impact on behavioral compatibility.

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

If this issue were being addressed before JDK 5 shipped or even during 
JDK 6, I would support changing the behavior of stripTrailingZeros.  
However, for addressing this in JDK 8, I think it is more appropriate to 
keep the behavior as-is and document this special case.


-Joe

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

[Stephen Colebourne]

On 4 February 2013 19:31, Joe Darcy joe.da...@oracle.com wrote:
 The stripTrailingZeros method has acted in this surprising way since the
 IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped
 in 2004.

 This situation is analogous to when the specification and behavior disagree.
 Our general policy to resolve such cases when evolving the JDK is:

 ..., there are times in evolving the JDK when differences are found between
 the specified behavior and the actual behavior (for example 4707389,
 6365176). The two basic approaches to fixing these bugs are to change the
 implementation to match the specified behavior or to change the
 specification (in a platform release) to match the implementation's (perhaps
 long-standing) behavior; often the latter option is chosen since it has a
 lower de facto impact on behavioral compatibility.
 http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html

 If this issue were being addressed before JDK 5 shipped or even during JDK
 6, I would support changing the behavior of stripTrailingZeros.  However,
 for addressing this in JDK 8, I think it is more appropriate to keep the
 behavior as-is and document this special case.

I don't see what JDK 5 vs 6 vs 8 really has to do with it. Sun/Oracle
has a large bug backlog, and this is just one of them. Fixing it is
not that hard, and I can't see how fixing it would be risky to the
world's applications.

Without this, people like us (OpenGamma) have to have work-arounds:
https://github.com/OpenGamma/OG-Platform/blob/master/projects/OG-Util/src/main/java/com/opengamma/util/JdkUtils.java#L26

Stephen

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

[Joseph Darcy]

On 2/4/2013 1:36 PM, Stephen Colebourne wrote:

On 4 February 2013 19:31, Joe Darcy joe.da...@oracle.com wrote:

The stripTrailingZeros method has acted in this surprising way since the
IBM-led JSR 13 was integrated into the platform back in JDK 5, which shipped
in 2004.

This situation is analogous to when the specification and behavior disagree.
Our general policy to resolve such cases when evolving the JDK is:

..., there are times in evolving the JDK when differences are found between
the specified behavior and the actual behavior (for example 4707389,
6365176). The two basic approaches to fixing these bugs are to change the
implementation to match the specified behavior or to change the
specification (in a platform release) to match the implementation's (perhaps
long-standing) behavior; often the latter option is chosen since it has a
lower de facto impact on behavioral compatibility.
http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html

If this issue were being addressed before JDK 5 shipped or even during JDK
6, I would support changing the behavior of stripTrailingZeros.  However,
for addressing this in JDK 8, I think it is more appropriate to keep the
behavior as-is and document this special case.

I don't see what JDK 5 vs 6 vs 8 really has to do with it.


The longer a particular behavior has been in a shipped JDK release, the 
more likely it is various people have built code that depend on that 
behavior.


-Joe