Upstream Jackson bug causing `BigDecimal` deserialization issues when missing leading zeros
oaklandcorp-jkaiser opened this issue · comments
Describe the bug
After trying to make the leap from Quarkus 3.2
to 3.8
I noticed an expected crash in automated tests around Jackson deserialization of the value .2
into a BigDecimal field. I believe this issue was tracked and resolved upstream with details found here.
It looks like the jackson-databind
patch 2.17.1
with the fix was already included in Quarkus 3.11.1
. I did upgrade to 3.11.1
and found the issue solved. Any chance you'd consider bringing this fix into the latest LTS branch 3.8
as well?
Expected behavior
A contract with field set correctly.
Actual behavior
com.fasterxml.jackson.databind.exc.InvalidFormatException: Cannot deserialize value of type `java.math.BigDecimal` from String ".2": not a valid representation
How to Reproduce?
See linked issue for a better example. Here is a minimalistic example.
Example contract
@Schema()
public class Contract {
@JsonProperty("fee")
@Schema(description = "a charge")
private BigDecimal fee;
}
Example input
{
"fee": .2,
}
Output of uname -a
or ver
Linux dev 6.5.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue May 7 09:00:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Output of java -version
openjdk version "17.0.6" 2023-01-17 LTS OpenJDK Runtime Environment Corretto-17.0.6.10.1 (build 17.0.6+10-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.6.10.1 (build 17.0.6+10-LTS, mixed mode, sharing)
Quarkus version or git rev
3.8.5
Build tool (ie. output of mvnw --version
or gradlew --version
)
3.8.6
Additional information
Placing this in the project's pom.xml
seems to workaround the bug while staying on the Quarkus 3.2
track.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson</groupId>
<artifactId>jackson-bom</artifactId>
<version>2.17.1</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
Thanks for the report! I marked #40584 for backport to 3.8.
Will close this issue and will post here if we decide against it in the end (I don't see any reason why we shouldn't backport it but we will discuss it with the backport team when we prepare the next 3.8).