Resolving to UnknownSerializer for a child bean after upgrading to 2.18.4 from 2.12.7

[PrashSi]

Problem: After upgrading the Jackson libraries from version 2.12.7 to 2.18.4, I'm running into an issue where one of the child beans is being serialized as empty when Service A calls Service B using the Jersey Client.

In the setup, Jackson is correctly serializing the QueryRequest and Platform beans, but somehow it's picking the UnknownSerializer when it tries to serialize the Keyword bean. This ends up serializing the Keyword bean as an empty bean.

The strange thing is that I don't see this issue if I add the @RequiredArgsConstructor(access = AccessLevel.PRIVATE) to the Keyword bean.

I'm wondering if anyone has any insights into why this could be happening?

Setup:

@Getter
@Builder(toBuilder = true)
@RequiredArgsConstructor(access = AccessLevel.PRIVATE)
@NoArgsConstructor(force = true)
public class QueryRequest {

   @NonNull
    private final Keyword keyword;

   @NonNull
    private final Platform platform;
}

@ToString
@Immutable
@Getter
@NoArgsConstructor(access = AccessLevel.PRIVATE, force = true)
public class Keyword implements Serializable {
    private final String text;
}

@Builder(toBuilder = true)
@Getter
@RequiredArgsConstructor(access = AccessLevel.PRIVATE)
@NoArgsConstructor(force = true)
public class Platform {
     private final String name;
}

[pjfanning]

We generally don't accept issues that involve 3rd party libs. Can you try reproducing this issue with just plain Java and Jackson libs - ie no lombok, no jersey?
Have you considered checking if the version of Jersey that you use supports Jackson 2.18?

[cowtowncoder]

Also, wrong repository, will move to jackson-databind.

[PrashSi]

I believe there was bug in previous version which got fixed later.

@Getter
public class QueryRequest {

    private final String id;
    private final String name;

    public QueryRequest(String id, String name) {
        this.id = id;
        this.name = name;
    }

    public static void main(String[] args) throws JsonProcessingException {
        QueryRequest req = new QueryRequest("id", "name");
        ObjectMapper mapper = JsonMapper.builder().configure(MapperFeature.REQUIRE_SETTERS_FOR_GETTERS, true).build();
        mapper.disable(SerializationFeature.FAIL_ON_EMPTY_BEANS);
        String json = mapper.writeValueAsString(req);
        System.out.println(json);

    }
}

The above code outputs different results for different version.

Version 2.11.4
Output: {"id":"id","name":"name"}

Version 2.18.4
Output: {}

JavaDoc for REQUIRE_SETTERS_FOR_GETTERS

Feature that determines whether getters (getter methods) can be auto-detected if there is no matching mutator (setter, constructor parameter or field) or not: if set to true, only getters that match a mutator are auto-discovered; if false, all auto-detectable getters can be discovered.
Feature is disabled by default.

Question - Wouldn't the constructor in the class above be considered a mutator method?

[PrashSi]

Ok I drilled further, and the only related change in 2.18.4 library is the fix introduced in 2.17 here line 403. This change adds additional check for field visibility && (_anyVisible(_fields))); which was missing in 2.12.

Right, ensure constructor is actually called during deserialization.

The issue is during serialization (not deserialization) when REQUIRE_SETTERS_FOR_GETTERS is to true. couldDeserialize check is returning false for all fields and Jackson couldn't find any properties to serialize and assigns UnknownSerializer.

My question is, would the constructor in my example above be considered as a mutator? If no, is there a work around apart from setting REQUIRE_SETTERS_FOR_GETTERS to false?

[cowtowncoder]

The issue is during serialization (not deserialization) when

Yes but what I want to determine if Constructor is auto-detected or not which is needed for property introspection.
One way is to see if deserialization actually uses it -- it will only do so if it's detected. From symptom it sounds like it isn't.

Another way to try things is to actually add explicit @JsonCreator on Constructor to force its detection. I would suggest doing that next.

My question is, would the constructor in my example above be considered as a mutator?

Constructor parameters would individually be considered mutators, yes (not Constructor, technically speaking, as it can have multiple parameters).

[cowtowncoder]

The issue is during serialization (not deserialization) when REQUIRE_SETTERS_FOR_GETTERS is to true.

Looking at example again, this might not be the case.

What you are missing are actual getters -- you only have private fields, which by default are not visible.
Setting REQUIRE_SETTERS_FOR_GETTERS has no effect on getters if none are found.
Unless @Getter is Lombok annotation that would generate such getters?

... which is why before doing any more troubleshooting we must get rid of all Lombok left, is any.
Not just for constructor. Stand-alone reproduction.

But if it's missing getters, what you need is either:

1. Add public getter methods OR
2. Make private fields visible: either with @JsonProperty, or by changing minimum visibility for Field auto-detection.

[PrashSi]

Sure, here is the stand-alone repro

public class QueryRequest {

    @JsonProperty("id")
    private final String id;
    private final String name;

    public QueryRequest(String id, String name) {
        this.id = id;
        this.name = name;
    }

    public String getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    // No mutator
    public String getAge() {
        return null;
    }

    public static void main(String[] args) throws JsonProcessingException {
        ObjectMapper mapper = JsonMapper.builder()
            .configure(MapperFeature.REQUIRE_SETTERS_FOR_GETTERS, false)
            .build();
        // Serialization
        QueryRequest req = new QueryRequest("id", "name");
        String json = mapper.writeValueAsString(req);
        System.out.println(json);

    }
}

Output: {"id":"id"}
Expected: {"name":"name","id":"id"}

Note - Adding @JsonProperty seems to be working.

[cowtowncoder]

Yes, your problem is that the no-parameters constructor is selected as creator and private Fields are not auto-detected.

So to avoid dropping "setterless" properties you need to indicate setters -- Fields or Constructor to use.