`@JsonProperty.value` + `@JsonIgnore` on setter does not work anymore since 2.18.4

[victor-noel-pfx]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

Hi,

The following fails since 2.18.4 (I tested also 2.20.1):

    class Test {
        private String prop = "someValue";

        @JsonProperty(value = "renamedProp")
        public String getProp() {
            return prop;
        }

        @JsonIgnore
        public void setProp(String prop) {
            this.prop = prop;
        }

        public static void main(String[] args) throws Exception {
            var m = new ObjectMapper();
            m.readValue(m.writeValueAsString(new Test()), Test.class);
        }
    }

This fails with:

Exception in thread "main" com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "renamedProp" (class example.Test), not marked as ignorable (one known property: "prop"])

I know that the best practice is to instead set the property as readonly but it's still a regression I guess?

Version Information

2.20.1

Reproduction

No response

Expected behavior

No response

Additional context

No response

[cowtowncoder]

Hmmmh. I think this might be working as expected: you are instructing setter to be ignored. Getter is renamed so serialization produces "renamedProp", but there's no matching setter for it.

I am not 100% sure what the intent would be but as presented this looks to me like expected behavior (possibly fixing a previous bug, even).

EDIT: re-reading, re-thinking, I think there was/is expectation that explicitly ignored properties are to be ignored, not just mutator. The problem here is the renaming, with "split" accessors.
It may be necessary to add @JsonProperty("renamedProp") next to @JsonIgnore....

At any rate this is not a supported case in sense that no unit tests existed to verify its functioning: it's more an edge case. My problem is that I honestly am not sure about expected semantics with such combination. :-(

[victor-noel-pfx]

@cowtowncoder I think I see what you mean but I'm not entirely sure ^^

If I try to rephrase, @JsonIgnore on the setter means that the whole property is ignored, not that the property is readonly.
And also that @JsonProperty on the getter (or anywhere else) always supersedes the @JsonIgnore.

So what I can conclude then is that:

• @JsonIgnore and @JsonProperty is really about defining/ignoring properties, not individual methods!
• the proper (and only?) way to achieve what I want is to mark the property as read only (I guess making the setter a noop would also work but seems more hacky)

That being said, there is still something a bit strange/confusing to me, if I write the following:

static class Test {
    private String prop;

    @JsonProperty
    public String getProp() {
        return prop;
    }

    public void setProp(String prop) {
        System.out.println("set called");
        this.prop = prop;
    }

    public static void main(String[] args) throws Exception {
        var m = new ObjectMapper();
        var t = new Test();
        t.prop = "someValue";
        System.out.println(m.readValue(m.writeValueAsString(t), Test.class).prop);
    }
}

2.18.3, 2.18.4 and 2.20.1 will print:

set called
someValue

This means that Jackson understood that the renaming also should be applied to the setter.

Now if I write this:

static class Test {
    private String prop;

    @JsonProperty("renamedProp")
    public String getProp() {
        return prop;
    }

    @JsonIgnore
    public void setProp(String prop) {
        this.prop = prop;
    }

    public static void main(String[] args) throws Exception {
        var m = new ObjectMapper();
        var t = new Test();
        t.prop = "someValue";
        System.out.println(m.readValue(m.writeValueAsString(t), Test.class).prop);
    }
}

2.18.3 will print

someValue

2.18.4+ will just fail with Unrecognized field "renamedProp"

And if I write this:

static class Test {
    private String prop;

    @JsonProperty
    public String getProp() {
        return prop;
    }

    @JsonIgnore
    public void setProp(String prop) {
        this.prop = prop;
    }

    public static void main(String[] args) throws Exception {
        var m = new ObjectMapper();
        var t = new Test();
        t.prop = "someValue";
        System.out.println(m.readValue(m.writeValueAsString(t), Test.class).prop);
    }
}

2.18.3, 2.18.4+ will print:

someValue

So the confusing thing to me is that in some case, the @JsonIgnore seems to actually ignore the setter, not the property, and the property is still deserialized (I guess the field is set directly via reflection instead).

Why renaming the field should change that situation? Why isn't the setter just ignored and thus reflection used to set the field for example?

Or is it the opposite and more cases should fail?

I guess all of this is corner cases so maybe nothing to be done here, but I wanted get clarification at least for me and anyone reading this 😛

[cowtowncoder]

Ok, right: @JsonIgnore and @JsonProperty DO affect the whole "logical property" -- so you need not duplicate annotations -- but ONLY as long as they all "agree" -- only Ignore OR only Inclusion (@JsonProperty) is used.
Also note that @JsonProperty has a secondary meaning, name choice (so either just "do include" or "do include, as XXX").
So, if there's just @JsonIgnore in all associated accessors, logical property is fully ignored.
If only @JsonProperty, then property included, possibly renamed.

However! In "split" case where different accessors have different annotations, we "unsplit" association: accessor with @JsonIgnore is ignored from processing (but name stored on deser side to quietly skip), and one with @JsonProperty (only) used (with possible new name).
New name can further add associations, "joining" other accessors.
As you can see, things get complicated quite quickly.

So the crux of the matter here is this: it looks like ignoral for setter used to be for renamed property, pre-2.18.4, but due to some change (likely fix for something else) made ignoral be applied before renaming.

I suspect that since we are 2 minor versions past, there is the question of where change to go back is safe: but if a localized fix is found, I'd be happy to apply it. But as per my notes above, handling is quite complicated, so not 100% sure fix with no regressions is possible.

FWTW, I think this regression is due to fix for #4628.

[cowtowncoder]

Ok: merged fix in 2.x (for 2.21.0) and will also be in 3.0(.3) / 3.1.0. Won't backport to earlier 2.x, to minimize risk of further regression there.