Although my attempts at serious work on 2.9 haven't borne fruit yet, I have spent some time investigating how to tackle my todo list:
https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.9 and I think I figured out how to combine entries #3 (allow merging of properties instead of always overriding) and #11 (allow overriding handling of `null`s from input). First one (#3) is my own top feature, to especially help with handling of Configuration use case, where merging (not overriding) default settings is useful; and actual merging of multi-level defaults would be even sweeter. Second one (#11) is favorite feature by all the Null Haters out there; and I have grown to appreciate some aspects of null-avoidance myself. As usual I really want to first think about how features would be used, from user perspective, both from perspective of desired behavior/functionality and ergonomics of how to get there. My first idea was to either introduce a new annotation (maybe for both), followed by desire to repurpose something like @JsonFormat. But more that I thought about this, more wrong use of `@JsonFormat` seems -- even if it would be convenient from impl perspective (since that annotation is extensively processed, nicely handled). And then it hit me: these both features affect behavior of "setters" (or, more appropriately, mutators). And we happen to have one rarely-used annotation already defined: @JsonSetter Now, starting with this, I am thinking of implementing something like this (but not necessarily exactly using these names, or even types): 1. Merge vs overwrite public class Config { @JsonSetter(merge=true) // or perhaps 'overwrite=false'? public NetworkSettings network = new NetworkSettingsImpl(1, false); } In this case, behaviour would be such that before deserializing value for 'network', attempt would be made to first use accessor (getter or field, whichever, if any, available), and if one found, use value accessed that way, modify it. And only if no getter available (or it returned `null` I suppose?), would a creator method (usually 0-arg ctor) used. Main benefit here really is that it is possible to define default settings and implementation types; and have class constructor or initializer blocks set them as appropriate, without deserializer replacing those object. I found this to be something that would help a lot with DropWizard style configuration. And it would also allow multi-level merging since `updateValue()` would work recursively, assuming merge settings were properly defined. Note, too, that `configOverrides()` should be defined to allow definition of per-type defaults. And perhaps even global default setting if feasible 2. Null-squashing for deserialization This is bit more complicated... so, the idea is that the current default behavior where incoming JSON `null`s get set as Java nulls can be dangerous and undesireable; and that although it is possible to define setters, it would be better allow a small set of canned alternative behaviors. Choices on what to do could include: (a) Just assign `null` (currently only choice; would be default still) (b) Throw an exception ("no nulls accepted here") (c) Ignore: leave property value as is (d) Replace with "default value" (as specified by JsonDeserializer.getEmptyValue()?) -- could be esp. useful for wrapper types, Collections, arrays, Maps * although, may be better handled at POJO as default values, ignore null? As with merging, there could/should be per-type `configOverrides()`, and possibly even global default setting. As to usage, I suspect this should be something like: public class NoNullsBean { // let's ensure we'll have a List no matter what @JsonSetter(nulls=JsonSetter.Nulls.IGNORE) public List<String> aliases = Collections.emptyList(); // Ok to omit, but not to try to set to `null` @JsonSetter(nulls=JsonSetter.Nulls.REJECT) public String extra; } ---- I hope above makes some sense; I am still trying to sort out the details myself (such as whether `USE_EMPTY` is actually necessary as null replacements, or not). But let me know if you like the ideas. -+ Tatu +- ps. Null-handling would, in all likelihood, NOT apply to missing values (except possibly with Creators) -- that's a whole another ball of wax, and fundamentally more difficult thing to improve upon. -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
