You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
public class OptionalnBean {
Optional<String> value;
@JsonCreator
public OptionalnBean(@JsonProperty("value") Optional<String> value) {
this.value = value;
}
}
with JSON like
{ }
current handling would assign Optional.empty() to value. But other reference types, like AtomicReference will instead assign null. This is to differentiate case of reading JSON like:
{ "value" : null }
in which value for all reference types becomes "empty" value (new AtomicReference<>, Optional.empty()).
This should be fixed for 2.14. But since this is a behavioral change it is also necessary to add configurability to allow old behavior, at least for 2.x.
And to maximize backwards compatibility we probably have to default to old and (IMO) sub-optimal handling.
The text was updated successfully, but these errors were encountered:
Ok, to configure new behavior -- absent (missing) Optionals becoming Java nulls you need to configure module, register it. So:
Jdk8Module module = new Jdk8Module()
.configureReadAbsentAsNull(true);
final ObjectMapper mapper = JsonMapper.builder()
.addModule(module)
.build();
This will be in 2.14.0 release.
cowtowncoder
changed the title
Optional deserialization for "absent" value should be null (like other Reference types), not "empty"
Allow Optional deserialization for "absent" value as Java null (like other Reference types), not "empty"
Sep 22, 2022
So, for case like:
with JSON like
current handling would assign
Optional.empty()
tovalue
. But other reference types, likeAtomicReference
will instead assignnull
. This is to differentiate case of reading JSON like:in which value for all reference types becomes "empty" value (new AtomicReference<>, Optional.empty()).
This should be fixed for 2.14. But since this is a behavioral change it is also necessary to add configurability to allow old behavior, at least for 2.x.
And to maximize backwards compatibility we probably have to default to old and (IMO) sub-optimal handling.
The text was updated successfully, but these errors were encountered: