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:
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
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
:-)
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/
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
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
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.
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
