JsonInclude.Include.NON_EMPTY does not replace deprecated WRITE_EMPTY_JSON_ARRAYS
See original GitHub issueIn moving from Jackson 2.7.6 to 2.8.3, we are now getting compiler warnings with regards to our use of the SerializationFeature.WRITE_EMPTY_JSON_ARRAYS. From what I can tell, the recommendation is to replace this with JsonInclude.Include.NON_EMPTY.
Our code previously looked like this:
public static ObjectMapper getJacksonObjectMapper() {
ObjectMapper mapper = new ObjectMapper();
mapper.configure(SerializationFeature.INDENT_OUTPUT, true);
mapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);
mapper.configure(SerializationFeature.WRITE_EMPTY_JSON_ARRAYS, false);
mapper.setSerializationInclusion(JsonInclude.Include.NON_EMPTY);
return mapper;
}
and when serializing JSON, empty arrays are omitted.
If I comment out the deprecated WRITE_EMPTY_JSON_ARRAYS line, and write the exact same object, the JSON has empty array elements within it.
Here is a simple test case, just unzip and run mvn package and look at the test output and you will see something that looks like the following:
Running test.EmptyArraysTest
Printing object with WRITE_EMPTY_JSON_ARRAYS set to false:
{ “id” : “123” }
Printing object without WRITE_EMPTY_JSON_ARRAYS:
{ “id” : “123”, “databases” : [ ] }
What am I missing?
jackson-empty-arrays-test.zip
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (6 by maintainers)
Top GitHub Comments
@rpatrick00 The problem here is that
MyClass
has override for@JsonInclude
:which will only suppress writing of
null
s; since it is more specific than global defaults it will have precedence.Another thing to note on replacement is that in addition to global inclusion default, and per-property annotation (that is, can put
@JsonInclude
on field/setter/getter), with 2.8 you can also specify type defaults:which should then make all
List<>
valued properties default to excluding empty, as well as null, values.Quick note here: if anyone wants to re-open the feature request, please do so at
jackson-databind
as Annotations package only deals with definition of annotations themselves and not any logic taken on them. If filing a new one (I’d rather do that than transfer this one), you can add reference this issue as background, but please summarize how “config overrides” is not workable solution.