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

Paul Sandoz paul.sandoz at oracle.com
Tue Feb 5 09:09:20 UTC 2013

On Feb 5, 2013, at 1:05 AM, Joseph Darcy <joe.darcy at oracle.com> wrote:

On 2/4/2013 1:36 PM, Stephen Colebourne wrote: On 4 February 2013 19:31, Joe Darcy <joe.darcy at 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=method&id=repository.grepcode.com%24java%24root@jdk%24openjdk@7-b147@java%24math@BigDecimal@stripTrailingZeros%28%29&k=u

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

Paul.

More information about the core-libs-dev mailing list