Upstream Jackson bug causing BigDecimal deserialization issues when missing leading zeros

[oaklandcorp-jkaiser]

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>

[quarkus-bot]

/cc @geoand (jackson), @gsmet (jackson)

[gsmet]

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