Why Java BigDecimal stripTrailingZeros leads to scientific notation-CodePudding

When you use stripTrailingZeros for number ending with zero like 10, 50, etc. BigDecimal.toString() method decided to use scientific notation ( instead 50 prints 5E 1) Here is example code tested with java 17:

public static void main(String[] asd)
{
    // prints: "with stripTrailingZeros: 5E 1"
    System.out.println("with stripTrailingZeros: "   new BigDecimal("50").stripTrailingZeros());

    // prints: "without stripTrailingZeros: 50"
    System.out.println("without stripTrailingZeros: "   new BigDecimal("50").toString());
}

I know both are correct but I'm wondering why not both return "50"?

This inconsistency is annoying because it propagates all over the application and in my case leads to inconsistency in my JSON API which is client facing (read by humans).

I know that I can fix this by using BigDecimal.toPlainString() but it feels wrong to force the serializer (in my case Jackson) to use this method with extra configuration just for this case.

CodePudding user response：

From the API documetation of stripTrailingZeros():

Returns a BigDecimal which is numerically equal to this one but with any trailing zeros removed from the representation.

What else would you expect that it returns? "5"?

CodePudding user response：

Thanks to @yshavit for his comment. Focused on my case working with decimals and removing trailing zeros in the decimal part, I totally forget that it will remove zeros from the non-decimal part also. So it is expected from new BigDecimal("50").stripTrailingZeros().toString() to return "5E 1" (without trailing zeros) instead of "50". From stripTrailingZeros() docs:

For example, stripping the trailing zeros from the BigDecimal value 600.0, which has [BigInteger, scale] components equal to [6000, 1], yields 6E2 with [BigInteger, scale] components equal to [6, -2].