On Wednesday, 7 March 2018 04:28:09 UTC, Tatu Saloranta wrote: > > On Tue, Mar 6, 2018 at 7:08 PM, <m...@vslice.co.uk <javascript:>> wrote: > > Thanks, Tatu. Is there any existing discussion around introducing this > as a > > feature? Missing and null properties are very different from a protocol > > point of view, not honouring the distinction seems like a big oversight. > > No. I disagree on importance of distinction here: I think trying to > treat cases differently is just asking > for trouble. There are no plans to add such state tracking, although > there is general wish to support > tracking of required fields that are set via setter or field, not just > constructor parameters. > > One simple mechanism would be to create a POJO with setter and then > either initialize values in a way > that lets you determine if setter was called or not, or make setter > update secondary status flag. > Alternatively you can bind content as `JsonNode` and look for > existence that way. > > To me keeping additional status on setters on databinding level just > does not make much sense, > > -+ Tatu +- >
Let me phrase this in a more objective way that's harder to disagree with. Firstly, in the specification (http://json.org/) missing and null properties are completely different categories. If I can't determine whether a property even exists that _is_ a fundamental limitation of the protocol implementation. Besides, you can already configure the treatment of null/missing for writes (@JsonInclude), and reads using mutable objects (setters). So why avoid implementing this for immutable objects? Let me know if I'm missing something, though. And thanks for the suggestions. I'm already using setters but they're obviously mutable, so I guess the only option is direct `JsonNode` binding as you say. > > > > > On Tuesday, 6 March 2018 03:16:42 UTC, Tatu Saloranta wrote: > >> > >> On Mon, Mar 5, 2018 at 6:14 PM, <m...@vslice.co.uk> wrote: > >> > For bean setters we have > >> > https://github.com/FasterXML/jackson-databind/issues/1402, which > AFAICT > >> > allows to specify different behaviour for nulls vs missing keys. > >> > > >> > I want to achieve the same but also preserve immutability (and > sanity). > >> > What's the simplest way of doing that? Sniffing around the code base > I > >> > see > >> > `PropertyValueBuffer._findMissing` just uses the deserializer's null > >> > value, > >> > and I don't understand Jackson's extension points well. > >> > > >> > In my case I'm using Java 8/9 Optionals and the observed behaviour is > as > >> > follows: > >> > > >> > - Field has a value: I get Optional.of(value) > >> > - Field is null: I get Optional.empty() > >> > - Field key is missing: I get Optional.empty() > >> > > >> > How do I distinguish between case 2 and 3? > >> > >> You can not distinguish them. You can get an exception, if you want, > >> by marking specific property/-ies > >> passed as required (@JsonProperty(required=true)), but that's it. > >> > >> -+ 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...@googlegroups.com <javascript:>. > > To post to this group, send email to jackso...@googlegroups.com > <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- 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.
