Parsing of `null` Integer fields changed behavior between version 2.11.4 and 2.12.X

[Crim]

Running version 2.11.4 using the following configuration:

        // Create new mapper
        final JacksonXmlModule module = new JacksonXmlModule();
        module.setDefaultUseWrapper(false);

        final XmlMapper mapper = new XmlMapper(module);

        // Configure it
        mapper
            .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
            .setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE)
            .registerModule(new JodaModule())
            .setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

Parsing the following xml:

        <campaign>
            <id>123</id>
            <name>Website Tracking</name>
            <cost/>
        </campaign>

into the following bean:

public class Campaign {
    private Long id;
    private String name;
    private Integer cost;

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public Integer getCost() {
        return cost;
    }

    public void setId(final Long id) {
        this.id = id;
    }

    public void setName(final String name) {
        this.name = name;
    }

    public void setCost(final Integer cost) {
        this.cost = cost;
    }
}

usage:

  // mapper instance as defined above, campaignXmlStr as defined above.
  mapper.readValue(campaignXmlStr, Campaign.class);

The above JSON gets deserialized into the bean with the cost property being set to null.

With version 2.12.x the cost property becomes integer 0

I reviewed the release notes and didn't notice any breaking change listed in behavior. Is this change expected?

Thanks!

[cowtowncoder]

This is XML-specific, so will move (jackson-core is for streaming API and JSON parsing).

[cowtowncoder]

I'll have to think about this for a bit -- change itself would not have been planned, but handling of "empty" values with XML is rather tricky as conceptually

<element />

is identical to

<element></element>

and in both cases logical textual content to process is empty String (""). Handling of that did change internally to allow dealing with this case for POJOs (to end up with "empty" Objects).

But I can see how such values should ideally become either null for Number wrappers or, in case of primitives like int, probably result in exception.

So I think that this change is a side effect of legitimate fixes for non-scalar types.

[Crim]

Yea, I suspect since the intent is ambiguous from just looking at only the XML (does empty mean null? or 0? or ...?) there's no "right" answer, other than to be opinionated one way or the other (and consistent) with how it's handled.

That said, it might be worth noting the change of behavior in the release notes.

Thanks! :)

[cowtowncoder]

@Crim fully agree wrt release notes for 2.12 at very least. I have an idea of how this might be relatively simple different wrt new-ish "coercion config" settings for XML module, but if so, how to change things 2.12 -> 2.13 (and if....) is the big question.

[cowtowncoder]

Actually I think I can fix the reported issue for 2.12.4; also created a related issue #474.

[cowtowncoder]

Should be fixed for integer/floating-point wrapper types as well as Boolean now, once 2.12.4 gets released (and 2.13.0).