Change of NON_EMPTY for Scalars (Fix #849) in 2.6 is not backward compatible

[kamenik]

Hi,

We have upgraded to Jackson 2.6.0 recently and it broke lots of our javascripts, they are very surprised by all zero values changed to undefined. It would be better to add another flag (NON_EMPTY_OR_ZERO) instead of changing current functionality.

[mastojun]

👍
I don't understand why 0 is considered empty. it is not empty, zero also actual number!

why don't you use NON_DEFAULT instead of NON_EMPTY?

[cowtowncoder]

@mastojun Concept of "empty" is arbitrary, but it does not mean "missing".
I am aware that zero is a number; but it is the default value of int, and so it was chosen as 'empty' value for numbers.

@kamenik Change was to address behavior, since zero was supposed to have been taken as empty from beginning; similar to empty String "" or boolean false. You can think of it as "default value for primitives".
We do not plan to add new flags, due to wide range of JsonFormat.Include values; but most likely you want NON_NULL or NON_ABSENT. NON_EMPTY has meant empty containers and default values for other types, and as unfortunate as backwards incompatibility is in this case, I don't think re-introducing the earlier flaw makes sense.

I am open to other ways to correct the problem however.

[cowtowncoder]

@mastojun One more thing: while NON_DEFAULT sounds like it should work, it actually has bit different semantics for POJOs: it excludes property values that have default values -- but this does not necessarily mean 0 for int (for example), as POJO may set different defaults with direct assignment or via constructor.

However: for primitives it should actually also work; so you can use settings interchangably.

I will need to at least upgrade javadocs for @JsonInclude to document expected behavior.

[Sovietaced]

I've tried using both NON_NULL and NON_ABSENT but this changes other behavior that breaks unit tests for us.

@cowtowncoder Is there a way to set SerializationInclusion on a specific type, namely numbers?

[einmalfel]

+1 to this issue: IMHO this will be counterintuitive even if you will mention this behaviour in docs
Enabling NON_EMPTY I expect it to skip empty collections, not integers with zero value

[cowtowncoder]

Regardless, the original intent was to consider default values for numbers to be empty.
I wish documentation was clear on this, as this is how values were meant to work.
I can see that from purely naming perspective this is not intuitive.

But the problem is that there is legitimate need/preference to also suppress zero numeric values, usually to reduce size of JSON serialization. Use of NON_DEFAULT could perhaps work, but its semantics are currently tied to POJO values, and not for stand-alone values.

Further, given that 2.6 does have clarified behavior, I am not sure I would want to make yet another behavior change in 2.7 to roll back changes.

With all this, note that there is not much benefit to +1:ing this issue -- issue tracker is not followed up by all (or even many) developers. The better place to argue for change in behavior is Jackson developer list at https://groups.google.com/forum/#!pendingmsg/jackson-dev.

[cowtowncoder]

Fixed via #952, included in 2.7.0-rc2.