Should there be support for "mis-serialized" Joda values (wrt https://github.com/FasterXML/jackson-datatype-joda/pull/115)

[Tatu Saloranta]

Quick question on how others feel about this PR:

https://github.com/FasterXML/jackson-datatype-joda/pull/115

which adds support for deserializing Joda date/time values that were
serialized without Joda module, as JSON Objects.
As I added in a comment, my first reaction is that I am not sure such
case should be explicitly supported, as it is sort of fail case and
adds code to maintain. However, I am not regular user and my instinct
does not always serve as good guidance on what users would find useful
and valuable.

So... WDYT?

-+ Tatu +-

ps. I also filed
https://github.com/FasterXML/jackson-databind/issues/2776 which is
orthogonal to this question -- making it easier to avoid
"mis-serialization", and guide users to add support module.

[Michael]

Not a regular user of joda time, but rather of Java 8 date time, however  some thoughts on the submitter's points: This seems to me to be a high-level "architectural" decision, so deserves some thought.

"Anyone serializing objects with Joda types who upgraded to Jackson 2.x without realizing this might have inadvertently serialized and persisted objects which are unserializable"

So this seems most likely to be a legacy issue that we wouldn't really see going forward, as I would consider the bulk of folks should have upgraded by now. Thus it seems to be adding more code to maintain as you've pointed out for a very narrow use case. Or is this (going back to the point about the 'architectural' decision), som

In that case, I think your fixes (like jackson-databind 2776 below) are very good, because that prevents this whole issue in the first place.

https://github.com/FasterXML/jackson-databind/issues/2776

"I can appreciate your reservations around adding this mitigation to the library because it can potentially mask a misuse of the library (i.e. failing to register the JodaModule with your ObjectMapper prior to serialization). IMO including this mitigation is a justifiable tradeoff as the the consequence is having undeserializable data"

This doesn't seem like a good tradeoff. And maybe I'm misunderstanding, but this isn't undeserializable data, it's just not able to be (understandably) deserialized back into a joda object (unless I'm missing something), without custom changes, such as in the PR. So it can be recovered and fixed. (Maybe another option here is a better error message, documentation, with a code snippet, on what do do in this situation?)

Can not deserialize instance of org.joda.time.DateTime out of START_OBJECT token

There's the point about Postel's law, but this looks more to me like correcting for bad data. Serializing it correctly and it works. Now to Cowtowncoder's point below, about using a separate module, if this really needs to be included, that seems like a better option.
 I was thinking of at least putting this behind a lenient/strict setting, or using the new CoercionConfig? 
Another possibility could be to create separate module, 

--
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 jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10ika%3DjZYPFUWk_1OA7JGcjE-uiqYkUTmGpVeXZoMwRdDw%40mail.gmail.com.

--

Written on a glass keyboard.