Add new JsonInclude.Include feature to exclude maps after exclusion removes all elements.

[cherlo]

Current exclusion features NON_NULL and NON_EMPTY help greatly in removing unwanted text in the json payloads, but maps still get serialized if they originally contained an element even when that child element is removed because it is null or empty. For example, when making a json tree from this json:

{ "foo" : {"bar" : null } }

then serializing with NON_EMPTY produces this:

{"foo" : {} }

but ideally, I want the payload to be:

{}

Seems trivial in this case, but when dealing with a realistic payload like:

{"familyCount":{},"zipCode":{},"areaCode":["555"],"streetAddress":{},"profileInfo":{},"marketInfo":{},"longitude":{},"latitude":{}}

I would rather have to deal with just this:

{"areaCode":["512"]}

These payloads are transported to mobile devices, logged and written to databases, so having them compact and readable is highly desirable. I ended up having to write a "JSON cleaner" that recursively prunes empty nodes to get a compact and readable payload.

It would be great if the ObjectMapper had a built-in serialization feature like NON_EMPTY that does this.

[cowtowncoder]

Value of Include.NON_DEFAULT should actually suppress serialization if value equals "default" value, which is defined as "object constructed using default no-argument constructor".
So it might work here.

[cherlo]

NON_DEFAULT produces the exact same result as NON_NULL. Here is an actual payload that correlates to a pojo and the json each feature produces. The payload includes all the different combinations of nulls and empty strings:

{"peopleKeyword":"","country":[],"zipCodeRadius":{"zipCode":"","distanceType":"","radius":""},"salesInfo":{"low":null,"high":null},"industryInfo":{"usSics":[]},"ipo":{}}

NON_DEFAULT:
{"peopleKeyword":"","country":[],"zipCodeRadius":{"zipCode":"","distanceType":""},"salesInfo":{},"industryInfo":{"usSics":[]},"ipo":{}}

NON_NULL:
{"peopleKeyword":"","country":[],"zipCodeRadius":{"zipCode":"","distanceType":""},"salesInfo":{},"industryInfo":{"usSics":[]},"ipo":{}}

NON_EMPTY:
{"zipCodeRadius":{},"salesInfo":{},"industryInfo":{},"ipo":{}}

NON_NULL and NON_EMPTY only ignored the nulls. I expected for NON_EMPTY to at least not write the empty map, but it didn't even do that. Just the empty arrays and strings.

[cowtowncoder]

Actually what I need to know is not so much JSON, but POJO definitions. Could you add class definition for the root value you are using here? All determinations are done at object level, without considering JSON.

[cowtowncoder]

Actually, ok, I think I see what you mean here.

So: determination of emptiness is done on source Map, and not on what actually gets included in JSON Object serialization.

Changing behavior here is quite difficult, due to sequencing of events that exclude empty values.
But perhaps this could be made to work, especially after implementing support for excluding empty values from Map (not just nulls).

[cowtowncoder]

#588 was implemented, and for 2.6 may allow solving the "recursive emptiness" problem, at least for some cases.

[cowtowncoder]

Missing piece was to add handling in MapSerializer, so that now following property:

 class POJO
{
        @JsonInclude(content=JsonInclude.Include.NON_EMPTY,
                value=JsonInclude.Include.NON_EMPTY)
        public Map<String,String> values;   

would produce

{}

for content where values only had "empty" values, such as nulls and empty Strings (""), or Lists with no elements.

[cherlo]

Thank you. Greatly appreciated.

On Thu, Nov 5, 2015 at 5:14 PM, Tatu Saloranta [email protected]
wrote:

Missing piece was to add handling in MapSerializer, so that now following
property:

class POJO
{
@JsonInclude(content=JsonInclude.Include.NON_EMPTY,
value=JsonInclude.Include.NON_EMPTY)
public Map<String,String> values;

would produce

{}

for content where values only had "empty" values, such as nulls and empty
Strings (""), or Lists with no elements.

—
Reply to this email directly or view it on GitHub
#497 (comment)
.

[SakerOmera]

This doesn't solve the nested POJO problem.

[kellerassel007]

solved.

[cowtowncoder]

@kellerassel007 As per my other comment, while I do not doubt you have an issue, it is not necessarily the same underlying problem. And since this issue is closed, a new issue with reproduction is needed.