Closed yushijinhun closed 4 years ago
Thank you for reporting this. I'll have to see what might be the correct behavior, given constraints; that is, whether it is possible to reliable support combination of ReferenceType
and unwrapped POJOs.
Ok, so I was able to resolve the issue as reported (used AtomicReference
for testing as databind can not depend on JDK8 types, but should work the same for Optional
). But since I am bit uneasy on whether this might cause issues elsewhere -- there are no test failures but combination of unwrapped and reference type is not super well tests -- decided to fix only for 2.11 (next minor version) and not for 2.10.x patches. Trying to get bit more cautious on what goes in patch vs minor version.
Was also wondering if this case should instead throw an exception (use of @JsonUnwrapped
on type that does not actually support unwrapping), but decided not to change semantics as no such checks have been made before.
Was also wondering if this case should instead throw an exception (use of
@JsonUnwrapped
on type that does not actually support unwrapping), but decided not to change semantics as no such checks have been made before.
I prefer to keep the current behavior. It is useful when I do not know the exact type of the field to be unwrapped. For example:
class TimestampedValue<T> {
@JsonProperty("_timestamp") long timestamp;
@JsonUnwrapped T value;
}
I prefer to unwrap the value
field since it's succinct. But this is not always possible, so I need this feature as a fallback.
Ok. Since it has not been blocked before, it seems reasonable to keep it that way even if this specific style of usage is not something I thought as original use case.
https://github.com/FasterXML/jackson-databind/blob/f315f1b22f47c9cfff2af9629910cb7c38c05463/src/main/java/com/fasterxml/jackson/databind/ser/std/ReferenceTypeSerializer.java#L300
I think change the expression to
may fix it, but
_valueSerializer
can be null here. Hoping anyone familiar with this can fix it.