-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing JsonNode field deserialized to null instead of NullNode #3389
Comments
@cowtowncoder Is this the new expected behavior? |
looks like this is intended: #3214 (comment) |
Correct: as per #3214 this works as intended and is the new expected behavior. If coercion from I am not sure if this is tested and would be interested in seeing if it does work or not yet (there is need for deseralizers to help). Tests for POJOs, enums etc can be found from:
(like and this also shows how to configure null conversions (via annotations or for ObjectMapper). |
Jackson was bumped upstream: confluentinc/common#446 Version 2.13 returns null instead of NullNode (cf FasterXML/jackson-databind#3389)
Jackson was bumped upstream: confluentinc/common#446 Version 2.13 returns null instead of NullNode (cf FasterXML/jackson-databind#3389)
Jackson was bumped upstream: confluentinc/common#446 Version 2.13 returns null instead of NullNode (cf FasterXML/jackson-databind#3389)
…9070) Jackson was bumped upstream: confluentinc/common#446 Version 2.13 returns null instead of NullNode (cf FasterXML/jackson-databind#3389)
Describe the bug
There's a behavior change between
2.12.6
and2.13.0
.Until then a missing
JsonNode
field was deserialized as aNullNode
and it now is deserialized to Javanull
.Version information
Behavior change occurs since
2.13.0
To Reproduce
With
2.12.6
this test passes successfully.Since
2.13.0
it fails asjsonNode
is deserialized tonull
.Expected behavior
After I've read a lot of issues related to
null
andNullNode
and I can't tell for sure what should be the expected behavior.But for sure that change can break some code relying on that.
Additional context
The change introduced in
2.13.0
to fix #3214 seems to be somewhat linked to this behavior change.The text was updated successfully, but these errors were encountered: