UnwrappedPropertyHandler serializes empty JSON Objects

[optimistdk]

Whenever I use @JsonUnwrapped annotation, my deserialized beans still are created even if all child values are null. I do set my object mapper to not include empty fields.

   protected static ObjectMapper writer = new ObjectMapper()
      .setSerializationInclusion(JsonInclude.Include.NON_EMPTY).
   disable(SerializationFeature.WRITE_NULL_MAP_VALUES).
   disable(SerializationFeature.WRITE_EMPTY_JSON_ARRAYS);

All empty pojos annotated with @JsonUnwrapped are serialized as { } .
So I end up having lot of empty structures:

details: {
    hoaFee: { },
    parking: { },
    pets: { },
    utilities: {
        landlordpays: { }
    }
}

While debugging i found that processUnwrapped was creating empty beans even if all values ( even nested pojos ) were null.

Can this be fixed in UnwrappedPropertyHandler to not deserialize empty values ( or respect JsonInclude.Include.NON_EMPTY )

other ref: http://stackoverflow.com/questions/31735669/jackson-jsonunwrapped-creating-empty-beans

[cowtowncoder]

Filtering nulls out only affects serialization: deserialization does not use this information for anything. So this part is by design, and there are no plans to change that. Behavior is not specific to unwrapped values.

What is the ultimate goal here? That is, what is the problem in creating empty POJOs from empty JSON Objects?

[optimistdk]

The ultimate goal is not have null values or null structures like i mentioned in the json output.

So the problem is even if empty pojos are created by design during deserialization, then during serialization, even if i set JsonInclude.Include.NON_EMPTY on the pojo it still returns an empty structure ( i guess thats because the serializer do write START { and END } even if the pojo is empty ).

I wanted to do this at deserializer level to make it cleaner.

[cowtowncoder]

Oh. So just to make it clear; these settings have no effect on deserialization.

But I understand what you would like to see for serialization: currently there is no way to prune out "empty" POJOs; only empty Collections, Maps, Strings and numbers.

Now: I assume that POJOs in question do have properties, but those properties get filtered out, being empty. If so, the problem is that filtering checks are based on Java objects, and not on JSON -- given this, check for isEmpty() simply sees that type is POJO, and has no way of determining "emptiness".

Would it be possible to add POJO definition here, just to make sure I understand the structure involved, and use of unwrapping? While I assumed it is not relevant, it is possible that some part of filtering might not be done same way for unwrapped values as for regular ones.

[optimistdk]

Thanks. Yes, a way to determine empty pojos and skip them during serialization would work for us.
[ Even a way not create empty bean during deser would work, but either is fine ]

Some sample pojo definitions i have:

public class Details {

 
   private Parking parking;
}

public class DetailsMixIn {

 
  @JsonUnwrapped
   private Parking parking;
}

public class Parking {
    private String spaceFeeType;
    private String spaceCost;
    private String comment;
    private List<String> types;
}

[optimistdk]

@cowtowncoder any follow up on this. Do we have any pointers or jira for this feature. Thanks.

[cowtowncoder]

@optimistdk No, there are no active plans to support feature for recursively figuring emptiness of POJOs.
I don't know how practical support using current system would be, either, since checks would need to be recursive and add significant overhead since property values would need to be accessed first for is-empty check, followed by a call to Serializers' isEmpty() methods; and if all returned true, indicating POJO value is to be skipped.

There may be an issue/RFE for (more) pluggable determination of exclusion with @JsonInclude by allowing specifying custom comparator (either just any Object, use equals() method).
While this would not be fully automatic (you would still need to implement simple comparison code), it would have benefits from implementation perspective, being both much simpler to implement, and also more efficient (since comparator can just directly check values).

Actually; I thought I had filed an issue for "custom inclusion", but I can't seem to find it.
I will add that; not sure if it would fit the use case here, but it's closest to something I have plans for.

[cowtowncoder]

Filed #888. There was indeed an older RFE as well, #558, but it had incomplete description of my current idea.

[optimistdk]

Thank you. We will wait for availability of
#888

On Wed, Aug 5, 2015 at 10:26 PM, Tatu Saloranta [email protected]
wrote:

Filed #888 #888.
There was indeed an older RFE as well, #558
#558, but it had
incomplete description of my current idea.

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

[cowtowncoder]

#888 is now implemented for 2.9.0 -- assuming this will allow intended behavior.
If not, I think a new RFE should be filed, explaining desired suppression of "empty" types.