On Wed, Jul 18, 2018 at 4:32 AM, Bogdan Vaneev <warchan...@gmail.com> wrote: > I am using jackson-databind 2.9.6: > > compile("com.fasterxml.jackson.core:jackson-databind:2.9.6") > > > And it looks like I found a bug. When object mapper is told to not include > nulls, it still includes if you read JSON to tree, then write to string from > this tree. > I wrote small example using groovy and spock: > > package jackson > > import com.fasterxml.jackson.annotation.JsonInclude > import com.fasterxml.jackson.databind.ObjectMapper > import spock.lang.Specification > > class ObjectMapperTest extends Specification { > def "should not include nulls"() { > given: > def json = ''' > { > "a": {}, > "b": [], > "c": "", > "d": 0, > "e": null > } > ''' > > def obj = [ > "a": [:], > "b": [], > "c": "", > "d": 0, > "e": null > ] > > def jsonMapper = new ObjectMapper() > .setSerializationInclusion(JsonInclude.Include.NON_NULL) > def tree = jsonMapper.readTree(json) > > > when: > def a1 = jsonMapper.writeValueAsString(tree) > def a2 = jsonMapper.writeValueAsString(obj) > > then: > a1 == a2 > } > } > > > > Because the same mapper is used, both a1 and a2 should not include key "e" > (its value is null). > > But the actual output is the following: > Condition not satisfied: > > a1 == a2 > | | | > | | {"a":{},"b":[],"c":"","d":0} > | false > | 9 differences (75% similarity) > | {"a":{},"b":[],"c":"","d":0(,"e":null)} > | {"a":{},"b":[],"c":"","d":0(---------)} > {"a":{},"b":[],"c":"","d":0,"e":null} > > Expected :{"a":{},"b":[],"c":"","d":0} > > Actual :{"a":{},"b":[],"c":"","d":0,"e":null} > > > Is that a bug?
No: JsonNode trees are not subject to most processing that is applied for POJOs, since inclusion criteria is defined for POJO properties, and nodes are not considered POJOs in this context. I realize that this is confusing as basically there are really multiple kinds of Java objects (POJOs and JsonNode differ, but Maps are yet another class... so at least 3) with diffierent processing models. Much of this is due to backend handlers being different, although part has to do with intended semantics too. My thinking from beginning has been that JsonNode is meant to represent JSON contents 1-to-1, with no changes or distortions, whereas POJO mapping is designed to apply various minor translations, in order to bridge the so-called impedance (Java object model, JSON model differing). This made sense to me, but I can see that it may not make sense to others, or could be matter of preference too. For Jackson 3.x it would be good to figure out how to define rules that are simpler (if possible), and applicability. I have some ideas on how that could work, esp. by "Class categories"; ability to define settings for "kinds" (categories) of classes -- like, "all Collections" or "all scalar types". If so, inclusion criteria could also be specified separately for "all JsonNodes". For Jackson 2.x it is probably not possible to change things much since existing behavior is what users count on, and changes could lead to regression in existing application code. I hope this helps. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user+unsubscr...@googlegroups.com. To post to this group, send email to jackson-user@googlegroups.com. For more options, visit https://groups.google.com/d/optout.