Jackson Error "no delegate- or property-based Creator" on trying to use record after upgrading to 2.15.3

[debraj-manna]

The below code is throwing the error with Jackson 2.15.3 but the same has been working fine with 2.14.3.

import com.fasterxml.jackson.annotation.JsonAutoDetect;
import com.fasterxml.jackson.annotation.JsonInclude.Include;
import com.fasterxml.jackson.databind.ObjectMapper;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

class JacksonTest {

  @Test
  void test() {
    var str = """
      {"id" : "test-rest"}
    """;

    var objectMapper = new BaseObjectMapper();
    try {
      System.out.println(objectMapper.readValue(str, TestResp.class));
    } catch (Exception e) {
      e.printStackTrace();
      Assertions.fail();
    }
  }

  record TestResp(String id) {}

  private static class BaseObjectMapper extends ObjectMapper {
    BaseObjectMapper() {
      setVisibility(
              getSerializationConfig()
                  .getDefaultVisibilityChecker()
                  .withFieldVisibility(JsonAutoDetect.Visibility.ANY)
                  .withGetterVisibility(JsonAutoDetect.Visibility.NONE)
                  .withIsGetterVisibility(JsonAutoDetect.Visibility.NONE)
                  .withSetterVisibility(JsonAutoDetect.Visibility.NONE)
                  .withCreatorVisibility(JsonAutoDetect.Visibility.NONE))
          .setSerializationInclusion(Include.NON_NULL);
    }
  }
}

The exception I am getting with Jackson 2.15.3 is like below

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `com.spotnana.obt.master.apis.auth.authentication.JacksonTest$TestResp` (no Creators, like default constructor, exist): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: (String)"  {"id" : "test-rest"}
"; line: 1, column: 4]
  at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:67)
  at com.fasterxml.jackson.databind.DeserializationContext.reportBadDefinition(DeserializationContext.java:1915)
  at com.fasterxml.jackson.databind.DatabindContext.reportBadDefinition(DatabindContext.java:414)
  at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1360)
  at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1424)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
  at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
  at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323)
  at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4825)
  at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3772)
  at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3740)
  at com.spotnana.obt.master.apis.auth.authentication.JacksonTest.test(JacksonTest.java:19)

Is this expected with Jackson 2.15.3? Can someone let me know what change in jackson 2.15.3 lead to this?

[pjfanning]

The release notes are here - https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.15

There were many changes in Jackson 2.15 to fix issues in Record support.

I would suggest that you should experiment with changing the visibility settings.

This is a volunteer project and it helps the volunteers if the reporters do some of the investigation.

[debraj-spotnana]

Yes if I remove withCreatorVisibility(JsonAutoDetect.Visibility.NONE)). It works.

But I am still trying to figure out from release notes which change actually caused this.

[debraj-spotnana]

FasterXML/jackson-databind#4105

It looks like the above issue

[cowtowncoder]

I would recommend trying this with just released 2.16.1. As @pjfanning mentioned there has been a lot of recent work to try to make record types work better, esp. with default settings. Conversely less common use cases -- like tweaking visibility settings -- are not as well covered.

But regardless of issue it is often best to try out later versions and see if the issue might already be fixed; this is often the case.
And even if not, the first step we maintainers do -- if not done by submitter -- is try a later version. Otherwise we may end up spending a lot of time troubleshooting already fixed problem (unless we happen to remember specific fix).

[cowtowncoder]

But specifically on this example: you have:

.withCreatorVisibility(JsonAutoDetect.Visibility.NONE))

which essentially says: "Do NOT try to find constructor for me, I will annotate one to use".
So it's perhaps no wonder that constructor is not found?

It may well be the case that 2.14 was incorrectly ignoring this visibility setting and 2.15 behavior is correct one.

So unless you really have a good reason to use that setting, I would remove it, or changed to at least find PUBLIC creators (constructors).

EDIT: above is incorrect, see my later comment.

[debraj-manna]

@cowtowncoder The behaviour of the 2.16.1 is the same as in 2.14.3. The above code is working fine with 2.16.1 also. I have placed the sample code in https://github.com/debraj-spotnana/jackson-issue/tree/main.

In 2.15.3 if I change the .withCreatorVisibility(Visibility.NON_PRIVATE)) then also it works.

I am a bit confused now, what is the correct behaviour? The explanation that you gave about .withCreatorVisibility(JsonAutoDetect.Visibility.NONE)) seems correct so why did it again change on 2.16.1?

[cowtowncoder]

@debraj-manna I think that behavior for 2.16.1 is what we want, after all. The tricky question is wrt. Records' canonical constructor which is the natural choice, as records do not have default no-parameter constructors (except in rare case of no-fields records).
So I may have misspoken earlier.

Now that think back, I think you should be safe, and that the Canonical constructor for records is found even without auto-detection. This is partly because -- as you pointed out -- up to 2.14 it was always detected.

We do not have plans to change this behavior in 2.16.x or later 2.x

Apologies for confusion.