Explicitly fail (de)serialization of java.time.* types in absence of registered custom (de)serializers
#2683
Comments
|
Implementing; appears to work, does not conflict with Java 8 date/time module when registered. About the only open question is this: initial implementation will throw deferred exception -- that is, only when actual attempt is made to read/write values. But should it be eager failure instead, at least for deserialization? (serialization might be trickier). |
|
If java 8 going to be minimum supported version at some point, can JavaTimeModule gets registered by default? |
|
Java 8 will be default for 2.13 (and was always at least Java 8 for Jackson 3.0). However, I am still not 100% sure about direct inclusion due to sheer size of Java 8 date/time module. |
Starting with FasterXML/jackson-databind#2683 Jackson will no longer use the generic bean serialization when serializing a `java.time.Instant`, but throw an error (since the bean serialization doesn't make sense for those types anyway). Our test relied on the bean serialization to test using custom object mappers. This PR improves the test to use a 'real' custom mapper instead of just relying on the bean fallback.
Starting with FasterXML/jackson-databind#2683 Jackson will no longer use the generic bean serialization when serializing a `java.time.Instant`, but throw an error (since the bean serialization doesn't make sense for those types anyway). Our test relied on the bean serialization to test using custom object mappers. This PR improves the test to use a 'real' custom mapper instead of just relying on the bean fallback.
(inspired by #2626)
So, a relatively common problem by users seem to be the case of using Java 8 date/time types, without registered Java 8 date/time module. For serialization this can even produce seemingly legit JSON output as values are considered just POJOs/Beans, which is problematic as JSON representation will NOT be what module would support, nor something that can be deserialized.
While general case of knowing that something is missing wrt support is unsolvable, the specific case of
java.timetype support may be something we could perhaps detect.My first idea is that when looking for (de)serializer, if no (de)serializer found via module registrations, trying to find one for
java.time.*classes should give specific failure suggesting that module is needed, and NOT try to create Bean[De]Serializer.Due to timing concerns (2.11.0.rc1 being tested, official 2.11.0 due soon) this will probably need to go in 2.12.0.
The text was updated successfully, but these errors were encountered: