On Thu, Feb 13, 2020 at 3:21 PM Michael Liedtke <[email protected]> wrote:
> Hello, > Amazon's Ion dataformat supports timestamps > <http://amzn.github.io/ion-docs/docs/spec.html#timestamp> and the Jackson > dataformats Ion > <https://github.com/FasterXML/jackson-dataformats-binary/tree/master/ion> > supports (de)serializing a timestamp value to/from java.util.Date and > java.sql.Date via IonTimestampSerializers > <https://github.com/FasterXML/jackson-dataformats-binary/blob/master/ion/src/main/java/com/fasterxml/jackson/dataformat/ion/IonTimestampSerializers.java> > and IonTimestampDeserializers > <https://github.com/FasterXML/jackson-dataformats-binary/blob/master/ion/src/main/java/com/fasterxml/jackson/dataformat/ion/IonTimestampDeserializers.java>. > I would like to expand the supported classes to include Java 8 java.time.*, > similar to what is provided with jackson-modules-java8/datetime > <https://github.com/FasterXML/jackson-modules-java8/tree/master/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: https://github.com/FasterXML/jackson-dataformats-binary/pull/133 (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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-user/85ac7d05-0309-4766-901b-a89ed1f2fdbe%40googlegroups.com > <https://groups.google.com/d/msgid/jackson-user/85ac7d05-0309-4766-901b-a89ed1f2fdbe%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/CAGrxA24sQfDeMoaxM5GojvfC8jFoXE7TtE5pJkc9LEuMicF12g%40mail.gmail.com.
