Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deserializing BigDecimal with large number of decimals result in incorrect value #4694

Closed
1 task done
lnthai2002 opened this issue Sep 11, 2024 · 6 comments
Closed
1 task done
Labels
2.17 Issues planned at earliest for 2.17 has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue
Milestone

Comments

@lnthai2002
Copy link

Search before asking

  • I searched in the issues and found nothing similar.

Describe the bug

I have a string represents a number with 652 decimal places (-11000.00000...). When reading this string to BigDecimal i end up with a wrong number -1.1000E-648. The simple example is found at https://github.com/lnthai2002/jackson-databind-test/blob/db3e060ac38c555b001d91c549e004a19f9a17c7/src/main/java/App.java

Version Information

2.17.1

Reproduction

<-- Any of the following

  1. Brief code sample/snippet: include here in preformatted/code section
  2. Longer example stored somewhere else (diff repo, snippet), add a link
  3. Textual explanation: include here
    -->
import com.fasterxml.jackson.core.JsonGenerator;
import com.fasterxml.jackson.databind.DeserializationFeature;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.node.JsonNodeFactory;

import java.math.BigDecimal;

public class App {
  public static void main (String [] args) {
    JsonNodeFactory f = JsonNodeFactory.withExactBigDecimals(true);
    ObjectMapper mapper = new ObjectMapper();
    mapper.findAndRegisterModules()
        .setNodeFactory(f)
        .configure(JsonGenerator.Feature.WRITE_BIGDECIMAL_AS_PLAIN, true)
        .configure(DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS, true);
    String str = "-11000.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000";
    try {
      BigDecimal num = mapper.readValue(str, BigDecimal.class);
      System.out.println(num);
    } catch (Exception e) {
      throw new RuntimeException(e);
    }
  }
}

Expected behavior

should print "-11000.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"

Additional context

If i switch back to 2.14.1 then i got the correct result

@lnthai2002 lnthai2002 added the to-evaluate Issue that has been received but not yet evaluated label Sep 11, 2024
@pjfanning
Copy link
Member

@cowtowncoder the issue is in FastDoubleParser JavaBigDecimalParser.parseBigDecimal(arr, 0, arr.length).

JavaBigDecimalParser.parseBigDecimal(str) handles the number fine but the char array method has a bug.

In Jackson 2.17, the BigDecimalParser uses the FastDoubleParser for BigDecimal when there are more than 500 chars.

I can report the issue to FastDoubleParser and also look at changing BigDecimalParser to work around the issue.

@cowtowncoder
Copy link
Member

Ok. Let's first see if we could get a fix for FDP... Ideally would not want to add temporary work-arounds, esp. given we are shading the dependency so can relatively freely upgrade.

I think I can add a failing test here, for 2.17, and we can see what to do (workaround vs upgrade) in couple of days.

cowtowncoder added a commit that referenced this issue Sep 11, 2024
@cowtowncoder cowtowncoder added has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue 2.17 Issues planned at earliest for 2.17 and removed to-evaluate Issue that has been received but not yet evaluated labels Sep 11, 2024
cowtowncoder added a commit that referenced this issue Sep 11, 2024
@cowtowncoder cowtowncoder changed the title Deserializing BigDecimal with large number of decimals result in incorrect value Deserializing BigDecimal with large number of decimals result in incorrect value Sep 13, 2024
@cowtowncoder cowtowncoder added this to the 2.17.3 milestone Sep 16, 2024
@cowtowncoder
Copy link
Member

Fixed in 2.17 (for 2.17.3) and 2.18 (for 2.18.0) -- fix actually via jackson-core, databind does have passing tests tho.

@lnthai2002
Copy link
Author

lnthai2002 commented Sep 19, 2024

there is no jackson-bom 2.17.3 ?

@pjfanning
Copy link
Member

there is no jackson-bom 2.17.3 ?

@lnthai2002 why are commenting on random closed issues? Jackson 2.17.3 has not been released.

@cowtowncoder
Copy link
Member

As per @pjfanning 2.17.3 is not yet released and it will take a while for it to be since there are just a couple of fixes, as per:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.17.3

and full patch release takes 2-3 hours to do. So this is not done for single bug fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.17 Issues planned at earliest for 2.17 has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue
Projects
None yet
Development

No branches or pull requests

3 participants