(TL;DNR: help appreciated by anyone deserializing `java.util.Date`s
using default settings -- code rewritten for 2.9.0, but after
2.9.0.pr4)

So: we are THIS close to getting final 2.9.0 -- there is literally
just one more thing I want to implement (databind #1583 --
https://github.com/FasterXML/jackson-databind/issues/1583 -- that is,
feature to force "bind the full input data"), which is relatively easy
to do.

But. I did also tackle one very old task: that of rewriting
`StdDateFormat`. This occurred after 2.9.0.pr4, so unfortunately it's
not testable through that.
Since this class is only used for deserializing `java.uti..Date` and
`java.util.Calendar`, and ONLY if NO custom format is set, it is quite
specialized a change. But it does have power to disrupt lots of use
cases, and probably mostly legacy ones (older code).
All unit tests pass, obviously, but due to complexity of date handling
(even if just for ISO-8601 subset like here) I do not feel 100%
comfortable there are no ill effects.
On plus side, new code is finally fully thread-safe and should also be
bit more efficient as an added bonus: these are due to replacing
`SimpleDateFormat` with basic regex Pattern, setting fields of
`GregorianCalendar`. And code is simpler too. So the change itself is
for good; I am just worried about edge cases for which there might not
be unit test.

So: if anyone could do a quick sanity test with regression suite, with
2.9.0 built from `master`, that would be much appreciated. As per
above, functionality affected is:

* Reading ISO-8601 Date/Calendar values, with no custom `pattern`
(alternative TimeZone, Locale will still call same code paths).
* Writing Calendar, Date values, similarly without custom `pattern`.

Bonus points for seeing how `leniency` settings affect deserialization
(ignore for serialization).

-+ Tatu +-

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to