1

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.

gshock
  • 584
  • 7
  • 18
  • Read my full question and you will find out why `toPlainString` is not a good choice for me – gshock Nov 27 '21 at 19:27
  • 2
    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 '21 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 '21 at 19:36
  • Why do you think it's inconsistent? – Louis Wasserman Nov 27 '21 at 19:38
  • new BigDecimal("50") prints "50" while new BigDecimal("50").stripTrailingZeros() prints "5E+1" Yes it's the same number but the representation (toString result) is not – gshock Nov 27 '21 at 19:39
  • 2
    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_ `BigDecimal`s. `new BigDecimal("50").equals(new BigDecimal("5E+1"))` is _false_. – Louis Wasserman Nov 27 '21 at 19:41
  • 4
    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 '21 at 19:46

2 Answers2

3

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

Reto
  • 1,305
  • 1
  • 18
  • 32
  • 2
    no I expect new BigDecimal().toString() for both to return "50" not "50" and "5E+1" – gshock Nov 27 '21 at 19:24
  • 1
    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 '21 at 19:32
  • 1
    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 '21 at 19:42
3

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

gshock
  • 584
  • 7
  • 18