Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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.
                Read my full question and you will find out why toPlainString is not a good choice for me
– gshock
                Nov 27, 2021 at 19:27
                This is perfectly normal and working exactly as BigDecimal is supposed to.  BigDecimals are always stored as number * 10^n.  It's no different whether n is positive or negative.  toString() is accurately reflecting the precision of the stored value.
– Louis Wasserman
                Nov 27, 2021 at 19:31
                @LouisWasserman  I know both are correct. What is bugging me is the difference of the BigDecimal.toString() result. It is inconsistent in the representation
– gshock
                Nov 27, 2021 at 19:36
                Yes, and...?  BigDecimal models how much precision you have with the value.  stripTrailingZeros() is telling BigDecimal, "Forget about the value of the ones digit.  Don't even show me a ones digit."  50 and 5E+1 are different BigDecimals.  new BigDecimal("50").equals(new BigDecimal("5E+1")) is false.
– Louis Wasserman
                Nov 27, 2021 at 19:41
                In "50", the "0" is a trailing zero. You asked the object to strip those, and you're upset that it did?
– yshavit
                Nov 27, 2021 at 19:46
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"?
                so you simply shouldn't call a method which transforms it to "5E+1" representation right before you implicitly call the toString()..
– Reto
                Nov 27, 2021 at 19:32
                In my case this is not possible. I need to use the .stripTrailingZeros() because sometime the numbers are  like 123.22000 etc. and I need to remove the trailing zeros
– gshock
                Nov 27, 2021 at 19:42
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" (with trailing zero). 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].
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.