JDK8 java.time.* native support for dataformat Ion

22 views
Skip to first unread message

Michael Liedtke

unread,
Feb 13, 2020, 6:21:13 PM2/13/20
to jackson-user
Hello,
Amazon's Ion dataformat supports timestamps and the Jackson dataformats Ion supports (de)serializing a timestamp value to/from java.util.Date and java.sql.Date via IonTimestampSerializers and  IonTimestampDeserializers. I would like to expand the supported classes to include Java 8 java.time.*, similar to what is provided with jackson-modules-java8/datetime.

I would be happy to take a stab at the support but I am curious what the best approach for this would be. From what I can tell from the release docs, the dataformat Ion project builds against Java 8 but aims to support a Java 7 runtime. Does this mean that java.time.* support could be added directly to the project under an optional ObjectMapper Module that can be used by consumers running Java 8 and higher? Would it be better to instead have a separate module like jackson-modules-ion-java8?

Thank you,
Michael

Tatu Saloranta

unread,
Feb 13, 2020, 6:55:19 PM2/13/20
to jackson-user
On Thu, Feb 13, 2020 at 3:21 PM Michael Liedtke <mcli...@gmail.com> wrote:
Hello,
Amazon's Ion dataformat supports timestamps and the Jackson dataformats Ion supports (de)serializing a timestamp value to/from java.util.Date and java.sql.Date via IonTimestampSerializers and  IonTimestampDeserializers. I would like to expand the supported classes to include Java 8 java.time.*, similar to what is provided with jackson-modules-java8/datetime.

Ok.

I think there is still on-going (although stagnant, partly as I haven't had time to focus on it) effort to do something like this with Avro:


(it actually covers bit larger area of things but does include date/time types)

 
I would be happy to take a stab at the support but I am curious what the best approach for this would be. From what I can tell from the release docs, the dataformat Ion project builds against Java 8 but aims to support a Java 7 runtime. Does this mean that java.time.* support could be added directly to the project under an optional ObjectMapper Module that can be used by consumers running Java 8 and higher? Would it be better to instead have a separate module like jackson-modules-ion-java8?

One quick note on that: while most modules do support Java7 runtime (but all require JDK 8 to build, partly since Sonatype OSS repo does not support pre-java 8 any more), at this point many modules could probably start requiring Java 8 baseline.
This is one case where I'd be ok with it assuming user community does not voice strong objections. That may be separate discussion.

On one vs two modules: no strong opinion here.

Now... this is one area where it seems like it'd be nice to have some mechanism for databind to introspect capabilities of streaming/format implementation, to basically check if there is a "native" representation for date/time types. If so, we would only need to change Java 8 date/time implementation to use newly added `writeXxx()` method(s) if supported (but only in that case!), which would then be translated by format implementation to actual encoding.
This seems doable for things that can be represented by `long`.
For backends (like json and other data formats, at least) that do not support specific encoding, serializer would default to String/timestamp write methods.

Another possibility that I also considered (and am still open to) is instead have overloads for `writeString()` and `writeNumber()`, which would basically be something like

  "writeStringFor(Object value, String representation)"
  "writeNumberFor(Object value, long serialization)"

which would have some advantages (impl could either use String/number as-is, or use alternative encoding) and disadvantages (suboptimal if caller already spent time to encode String representation; more type-checking/casting logic).

Having said that, I am not against straight-forward override of (de)serializers. But think that there might be some synergy in splitting tasks between databind and streaming layers.

-+ Tatu +-

 

Thank you,
Michael

--
You received this message because you are subscribed to the Google Groups "jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/85ac7d05-0309-4766-901b-a89ed1f2fdbe%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages