Deserialization using `@JsonCreator` with renamed property failing (since 2.18)

[jmesny]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

Hello,

Since v2.18, some of our data classes failed to be used for deserialization.
Those classes are making use of @JsonProperty et @JsonCreator annotations, and rely on the ParameterNamesModule.

Version Information

2.18.1

Reproduction

Example reproducing the issue:

import com.fasterxml.jackson.annotation.JsonCreator;
import com.fasterxml.jackson.annotation.JsonProperty;
import com.fasterxml.jackson.databind.json.JsonMapper;
import com.fasterxml.jackson.module.paramnames.ParameterNamesModule;
import com.google.auto.value.AutoValue;
import org.junit.jupiter.api.Test;

import static com.google.common.collect.Sets.newHashSet;
import static org.assertj.core.api.Assertions.assertThat;

public final class MappingIssueTest {

    @AutoValue
    public static abstract class DataClassWithPropRenaming {
        @JsonProperty("bar")
        public abstract String getFoo();

        @JsonCreator
        public static DataClassWithPropRenaming create(String bar) {
            return new AutoValue_MappingIssueTest_DataClassWithPropRenaming(bar);
        }
    }

    @Test
    void shouldSupportPropertyRenaming() throws Exception {
        var mapper = JsonMapper.builder()
                .addModule(new ParameterNamesModule())
                .build();

        var serializationResult = mapper.valueToTree(DataClassWithPropRenaming.create("42"));

        assertThat(newHashSet(serializationResult.fieldNames()))
                .containsExactlyInAnyOrder("bar");

        var deserializationResult = mapper.treeToValue(serializationResult, DataClassWithPropRenaming.class);

        assertThat(deserializationResult)
                .isEqualTo(DataClassWithPropRenaming.create("42"));
    }
}

Fails with the following error:

com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `MappingIssueTest$DataClassWithPropRenaming` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: UNKNOWN; byte offset: #UNKNOWN]

	at com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
	at com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1754)
	at com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1379)
	at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1512)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:348)
	at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:342)
	at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:4893)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3036)
	at com.fasterxml.jackson.databind.ObjectMapper.treeToValue(ObjectMapper.java:3500)

Expected behavior

We would expect that the @JsonCreator method parameter name be used to map the field having the same name in the JsonNode.

Additional context

Adding a @JsonProperty("bar") on the creator parameter solves the issue.

[pjfanning]

Please try 2.18.2. This issue sounds similar to issues that were fixed in that release.

[K-Fl]

There is no 2.18.2?

[JooHyukKim]

Try building latest 2.18 branch. That would be 2.18.2?

[jmesny]

I tried with the 2.18 and 2.19 branches, the issue is still here.

[yihtserns]

Observations (tested without AutoValue, though):

1. A workaround is setting @JsonCreator.mode = PROPERTIES.
2. Automagically works when @JsonCreator is removed.

[jmesny]

I provided a simplified example. In real life, we don't really have any single-argument factory methods that could use this DELEGATING mode.

[yihtserns]

Eh sorry I meant PROPERTIES not DELEGATING, updated that incorrect comment. 😅

[cowtowncoder]

I would strongly recommend against using plain @JsonCreator for 1-argument constructor/factory method: use of mode = Mode.PROPERTIES. Other than that, it seems like a flaw in heuristics: if name bar is recognized this should be considered Properties-style Creator.

[cowtowncoder]

Ok, I can reproduce this, and the problem is that heuristics for mode detection only have access to properties before renaming, accessible only by implicit name. In 2.17 handling was done at a later point where access was post-renaming.

I'll need to see if there is any way to be able to access explicit renaming.