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.DateTim*e 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, * On Thu, Jun 25, 2020 at 1:38 PM Tatu Saloranta <t...@fasterxml.com> wrote: > 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. > > -- > 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAEBemP3X6F9M-jVGndoeMdj_ma7af_82mqC%3DWpYYibb-wZVXog%40mail.gmail.com.
