JsonAnyGetter method serialization can override JsonProperty serialization on serialized name conflict

[alzimmermsft]

Search before asking

• [x] I searched in the issues and found nothing similar.

Describe the bug

It would appear this change https://github.com/FasterXML/jackson-databind/pull/4775 (fixing #4388) broke a rather niche scenario where if you had a @JsonProperty("x") and @JsonAnyGetter public Map<String, Object> x it would override the BeanWriterProperty.

The scenario we had tests for shouldn't be used anymore, so this is a low priority for us, just wanted to report as it is a breaking change on upgrade and was really hard to track down.

Version Information

Starting in 2.19.0

Reproduction

Use this class for serialization

public class Repo {
    @JsonIgnore
    private Map<String, Object> additionalProperties;
    @JsonProperty(value = "additionalProperties")
    private Map<String, Object> additionalPropertiesProperty;

    @JsonAnySetter
    private void additionalProperties(String key, Object value) {
        if (additionalProperties == null) {
            additionalProperties = new HashMap<>();
        }
        additionalProperties.put(key.replace("\\.", "."), value);
    }

    @JsonAnyGetter
    public Map<String, Object> additionalProperties() {
        return additionalProperties;
    }

    public Map<String, Object> additionalPropertiesProperty() {
        return additionalPropertiesProperty;
    }

    public void additionalPropertiesProperty(Map<String, Object> additionalPropertiesProperty) {
        this.additionalPropertiesProperty = additionalPropertiesProperty;
    }
}

Create the following object

Repo repo = new Repo();
repo.additionalProperties("foo", "bar");
repo.additionalPropertiesProperty(Collections.singlontonMap("fizz", "buzz");

In Jackson 2.19.0 this serializes as {"foo":"bar"}, before Jackson 2.19.0 this serializes as {"foo":"bar","additionalProperties": {"fizz":"buzz"}}

[cowtowncoder]

Thank you @alzimmermsft this does look like a regression to me.

EDIT: let me re-read -- not sure what should occur. It is confusing example.

[JooHyukKim]

Will work on a fix. Thank you again @alzimmermsft !

[cowtowncoder]

In this case, I think I would actually suggest avoiding confusing/conflicting naming.

So the original caveat may apply. If we can work around conflicts easily, great; but I don't want to complicate handling itself a lot to address niche case.

[alzimmermsft]

That works in my case, as this was found in testing, and since we own that I just removed the test as we don't really use the affected code path anymore. Moreso wanted to document this for the community in case anyone else ran into it.