Serialization of the field with deserialization config

[metanet]

Hello,

(I am copying the issue from FasterXML/jackson-core#112 with @cowtowncoder 's suggestion)

I am talking about jackson version 1.9.13.

Here is the demonstration of the bug.

public class TestClass { 

    private final int a;

    public TestClass (final int a )
    {
        this.a = a;
    }

    @JsonProperty("b")
    private int getA ()
    {
        return a;
    }
}

When I serialize new TestClass( 5 ), I get this json: {"b":5}

Now I am changing my code to this version:

public class TestClass { 

    private final int a;

    public TestClass (@JsonProperty("a") final int a )
    {
        this.a = a;
    }

    @JsonProperty("b")
    private int getA ()
    {
        return a;
    }
}

When I serialize new TestClass( 5 ), I get this json: {"a":5,"b":5}
Here, I am not expecting the field "a" in the serialized json, I only expect it during the deserialization.

Because of the legacy data, I needed to serialize and deserialize a field with different names. My code was working fine with jackson 1.8 version. When I updated to jackson 1.9, this bug appeared and possibly screwed up various parts of my dataset (which is in size of a couple of hundred million records).

By the way, this bug does not exist in Jackson 2.2.

[cowtowncoder]

Interesting. One thing I am wondering is whether missing @JsonCreator from constructor matters here -- it certainly makes it likely that constructor is never used (and deserializer instead tries to modify field: JVM allows this, with some constraints!).

[cowtowncoder]

Hmmh. I actually get an exception with 2.2.3.

[mtyurt]

Any improvements on this issue?

[cowtowncoder]

No. If anyone has time feel free to work on it.

[cowtowncoder]

Interesting: looks like test would work as expected for 2.4 (master) -- I added test case, it is passing.

[cowtowncoder]

Checked with 2.3: still failing with 2.3.2. So this is due to a recent fix, although indirect one: most likely one for #369.

[cowtowncoder]

Status with 2.4 is bit unclear; only now fully understanding where the problem comes from -- difficulties in differentiating between implicit (from underlying accessor name) and explicit (annotation) names, and how conflict resolution deals with the two.

[cowtowncoder]

Ok. After fixes to handling of implicit names, at this point I realize that there is a real conflict: field a could either be renamed along with setter or constructor. So it is necessary to add explicit @JsonProperty for it; or, to use @JsonIgnore to remove it from consideration: both approaches should work.

I will modify test accordingly to verify that above-mentioned approaches work.

[cowtowncoder]

Tests pass, as long as field a is explicitly named (for example as either a or b), or marked as to be ignored. This with 2.4.0, soon to be released.