Deserialization behavior change with @JsonCreator and @ConstructorProperties between 2.17 and 2.18

[gssbzn]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

We maintain a large codebase which has some legacy classes that use Hungarian notation and lombok,

Deserialization used to work up until the 2.18 update where jackson is no longer respecting the @ConstructorProperties to match the constructor properties and we are now seeing cannot deserialize from Object value (no delegate- or property-based Creator) errors.

This may be related to INFER_CREATOR_FROM_CONSTRUCTOR_PROPERTIES and the recent rewrite POJO Property Introspection

Version Information

2.18.2

Reproduction

@Test
  void deserialization() throws JsonProcessingException {
    var json =
        """
{
  "value": "test"
}
""";
    var result = new ObjectMapper().readValue(json, Something.class); // throws error

    assertEquals("test", result.getValue());
  }

  private static class Something {
    @JsonProperty("value")
    private final String _value;

    String getValue() {
      return _value;
    }

    @JsonCreator
    @ConstructorProperties({"value"})
    Something(String pValue) {
      _value = pValue;
    }
  }

Expected behavior

jackson should be able to leverage @ConstructorProperties for the @JsonCreator

Additional context

No response

[cowtowncoder]

Thank you for reporting this @gssbzn. It definitely sounds like bug.

[cowtowncoder]

Oh. But this looks odd:

    @JsonCreator
    @ConstructorProperties({"value"})
    Something(String pValue) {
      _value = pValue;
    }

Use of @JsonCreator is redundant. So while it should not cause problems, I'd remove that just as basic clean up. And it might also work around the issue (haven't checked yet but guessing it might actually be causing problem).
That is: you don't need @JsonCreator if you have @ConstructorProperties: latter implies former (with mode = JsonCreator.Mode.PROPERTIES)

[cowtowncoder]

Found the reason: @JsonCreator has default mode (Mode.DEFAULT) which overrides @CosntructorProperties-implied Mode.PROPERTIES. Will fix.

[cowtowncoder]

Fixed. Thank you @gssbzn for reporting this! Will be in 2.18.3 release.

[nipanwar77]

Hi @cowtowncoder , since this is a part of 2.18.3, when is it expected to be released any timeline? We need the patch urgently and there is no due date assigned

[pjfanning]

@nipanwar77 can't you use 2.17 until new releases are made?

[nipanwar77]

@pjfanning We need to move to spring-boot 3.4.0 for security reasons and we are not able to use 2.17 with it.

[deepakraghav0]

@pjfanning I checked that there is no open issue for 2.18.3 at your end, can we get patch soon :)

[pjfanning]

@pjfanning I checked that there is no open issue for 2.18.3 at your end, can we get patch soon :)

There is other work happening. 2.18.3 will happen when it happens. Please provide a detailed description of why you can't use an older version of Jackson. Releases involve a lot of work.

Have you even tried overriding the Jackson version in your build? What proof do you that spring-boot needs an exact version of Jackson and can't be used with other recent versions of Jackson?

[cowtowncoder]

@deepakraghav0 Things are bit hectic with 3.0.0-rc1 work, so 2.18.3 will probably happen in early March. Like @pjfanning indicated, full release takes quite a bit of effort (2.5 - 4 hours of my time) and I don't work on Jackson full time so unfortunately finding chunk of "free" time is not always easy.
(and unfortunately there's neither easy way to speed up release or delegate to other team members).

But I definitely also want to get 2.18.3 out, it's pretty well loaded with fixes:

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

[deepakraghav0]

Hello @cowtowncoder , sorry for the late reply. I noticed that version 2.18.3 was released on February 28th. Thanks for the update!

@pjfanning we have some complex scenarios that require version 2.18.3. Now that it is available, it should work for us.