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

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]

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]

thanks!