Support reading `java.util.Calendar` / `java.util.Date` from textual serialization

[Marty]

Hi,

I'm writing a list of instances of my class that has a calendar field.

File file = new File(context.getFilesDir(), fileName);
try {
    JSON.std.write(listOfObjects, file);

Writing works just fine, but when reading the created json, I receive the following exception:

com.fasterxml.jackson.jr.ob.JSONObjectException: Can not get long numeric value from JSON (to construct java.util.Calendar) from JSON String

I can fix this easily by adding the JSON.Feature.WRITE_DATES_AS_TIMESTAMPto the writer, but I find it rather odd that jackson-jr is not able to read what it has written with complete default configuration.

I'm using 'com.fasterxml.jackson.jr:jackson-jr-objects:2.7.4'

[cowtowncoder]

At this point jackson-jr only supports textual serialization, not reading back, of JDK date/time values.
This is because serialization is easy and can be done without extra configuration, using default toString() of Date and Calendar. This is not particularly good way, but does allow human-readable representation.

To support deserialization would require quite a bit of work since formats would typically need to be configurable as there are multiple flavors of ISO-8601 meta-standard (that is, almost unlimited variety of things that are legal ISO-8601; and no good JDK support to deal with general case, if that's even possible).

So. I'll leave this open and may edit the title to suggest that jackson-jr should support deserialization of textual date/time values, instead of serialization. But it may be that this might be easiest supported by allowing some rudimentary support custom datatype writers/readers (serializers/deserializers), and letting users implement those: most users have specific and more limited needs, which can be implemented in simpler ways than what framework has to support.

[cowtowncoder]

Slightly related: Jackson 2.10 added ability to register custom ValueReaders and ValueWriters (see #65), and allows packaging of such types as JacksonJrExtensions. So adding support for "classic" Date, Calendar, Joda date/time and Java 8 date/time types should now be easier, in reusable manner.

[cowtowncoder]

Possible alternative approach: #100 added (very) limited support for Java 8 date/time types. Could/should be extended; could also be extended for better support for java.util.Date / Calendar types.