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

Cannot deserialize value of type java.math.BigDecimal from String ".05": not a valid representation #4435

Closed
1 task done
EAlf91 opened this issue Mar 16, 2024 · 2 comments
Labels
2.17 Issues planned at earliest for 2.17

Comments

@EAlf91
Copy link

EAlf91 commented Mar 16, 2024

Search before asking

  • I searched in the issues and found nothing similar.

Describe the bug

We faced an issue with the newest release of jackson 2.17 while deserializing BigDecimals from JsonInput with a string value of the format ".f" e.g. {"value":".03"}

When deserializing using a standard ObjectMapper this exception is thrown.

com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `java.math.BigDecimal` from String ".05": not a valid representation
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); line: 1, column: 10] (through reference chain: TestDTO["value"])

	at com.fasterxml.jackson.databind.exc.InvalidFormatException.from(InvalidFormatException.java:67)
	at com.fasterxml.jackson.databind.DeserializationContext.weirdStringException(DeserializationContext.java:1958)
	at com.fasterxml.jackson.databind.DeserializationContext.handleWeirdStringValue(DeserializationContext.java:1245)
	at com.fasterxml.jackson.databind.deser.std.NumberDeserializers$BigDecimalDeserializer.deserialize(NumberDeserializers.java:1058)
	at com.fasterxml.jackson.databind.deser.std.NumberDeserializers$BigDecimalDeserializer.deserialize(NumberDeserializers.java:990)
	at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:129)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:310)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:177)
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
	at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4905)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3848)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3816)
	at BigDecimalTest.shouldDeserializeBigDecimalFromJacksonDataBind(BigDecimalTest.java:27)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

Version Information

2.17

Reproduction

I created a small project with two unit tests, one using NumberInput.parseBigDecimal from jackson-core which is running fine as well as test which is deserializing the same value from a json input.

@Test
public void shouldDeserializeBigDecimalFromJacksonCore() {
    BigDecimal actualFromJacksonCore = NumberInput.parseBigDecimal(".05", true);
    assertEquals(expected, actualFromJacksonCore);
}

@Test
public void shouldDeserializeBigDecimalFromJacksonDataBind() throws JsonProcessingException {
    BigDecimal actualFromJacksonDataBind = mapper.readValue("""{"value":".05"}""", TestDTO.class).getValue();
    assertEquals(expected, actualFromJacksonDataBind);
}

https://github.com/EAlf91/jackson-issue

Output from the tests:
image

Expected behavior

I would expect jackson-databind to be able to deserialize the given input as both jackson-core and FastDoubleParser which jackson is relying on both can handle it.

The Changelog also does only mention an enum related change which seems unrelated to the behaviour described in this issue.

Additional context

One of the changes here might have caused this behaviour:
ce9c629

@EAlf91 EAlf91 added the to-evaluate Issue that has been received but not yet evaluated label Mar 16, 2024
@pjfanning
Copy link
Member

Does this work with Jackson 2.16? I can see a change in Jackson 2.17 that may have changed the behaviour.

@EAlf91
Copy link
Author

EAlf91 commented Mar 16, 2024

@pjfanning hey, yes 2.16 is perfectly fine. I linked the prevalidation change in the "Additional Context" section of this issue. There's a comment explicitly mentioning 2.17

@cowtowncoder cowtowncoder added 2.17 Issues planned at earliest for 2.17 and removed to-evaluate Issue that has been received but not yet evaluated labels Mar 23, 2024
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
Projects
None yet
Development

No branches or pull requests

3 participants