enable jackson ObjectMapper JDK8 & JSR310 modules + module autodetect

[rursprung]

Description

see the individual commit messages for further details.

short summary: this makes using core java types introduced 10+ years ago possible without having to resort to manual workarounds on the client side.

with jackson 3.x this will work out of the box since they've included the modules there. jackson 3.0 will probably be released soon, since RC5 is already out; though how/when opensearch-java will upgrade to this is unclear to me since it's part of the public API (and you just did a major release).

Issues Resolved

n/a

though this relates to #250 & #251

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[reta]

@rursprung AFAIK none of the OpenSearch Java APIs expose or use java.time.* APIs, please correct me here. What problem you are solving?

[rursprung]

@reta: see the provided test: it's not about what opensearch-java does internally. it's about the classes you try to ingest. without this you cannot serialise/deserialise any data which contains java.time.* fields.

[reta]

@reta: see the provided test: it's not about what opensearch-java does internally. it's about the classes you try to ingest. without this you cannot serialise/deserialise any data which contains java.time.* fields.

@rursprung two things here:

1. The opensearch-java does not control user defined types (including Date/Time since this is not part of model)
2. The OpenSearch has a wide variety of date/time format options which Jackson module is not aware of and won't be able to serde properly (see please https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/common/time/DateFormatters.java)

To summarize, the serde of date/time fields needs care, there is no default we could / should use, I believe the users should add the serde manually (and if the standard work for them - even better, register module(s) or delegate to framework like Spring)

[rursprung]

1. The `opensearch-java` does not control user defined types (including Date/Time since this is not part of model)

i agree. but JDK8 data types are part of the core language. opensearch-java does not support older java versions. the only reason why this isn't enabled by default is because jackson 2.x still does. with 3.x they drop JDK7 support and auto-enable all the things which i manually enable here.

2. The OpenSearch has a wide variety of date/time format options which Jackson module is not aware of and won't be able to serde properly (see please https://github.com/opensearch-project/OpenSearch/blob/main/server/src/main/java/org/opensearch/common/time/DateFormatters.java)

this is a different topic. what you're linking to is about indexing text which then gets parsed as dates. what i'm talking about is indexing native java date/time values

To summarize, the serde of date/time fields needs care, there is no default we could / should use, I believe the users should add the serde manually (and if the standard work for them - even better, register module(s) or delegate to framework like Spring)

i disagree with you on this: these are standard java.time.* data types which are 100% standardised and it's exactly clear how serde needs to work for them. that's why jackson has a standard implementation for it (and it was only excluded from the default for historical JDK7 reasons which are now moot).

if - after re-considering my arguments 😉 - you're still completely against adding the JDK8 & JSR310 modules as dependencies: would you at the very least accept adding the module autodetection to opensearch-java? then it'd be enough for consumers to just put them on the classpath without having to manually instantiate it.

[reta]

if - after re-considering my arguments 😉 - you're still completely against adding the JDK8 & JSR310 modules as dependencies: would you at the very least accept adding the module autodetection to opensearch-java? then it'd be enough for consumers to just put them on the classpath without having to manually instantiate it.

Sorry for delay @rursprung , I think adding findAndRegisterModules would not harm (and users do have a choice to overrule this behavior by providing custom ObjectMapper instance). @Xtansia what do you think? Thank you.

[rursprung]

if - after re-considering my arguments 😉 - you're still completely against adding the JDK8 & JSR310 modules as dependencies: would you at the very least accept adding the module autodetection to opensearch-java? then it'd be enough for consumers to just put them on the classpath without having to manually instantiate it.

Sorry for delay @rursprung , I think adding findAndRegisterModules would not harm (and users do have a choice to overrule this behavior by providing custom ObjectMapper instance). @Xtansia what do you think? Thank you.

i've now split the first commit out into #1643
i still think that we should also enable the modules, but am already happy if auto-detect is enabled. thus i created a new PR (so that we can keep the discussion around adding modules here while moving ahead with auto-detect). if the final verdict stays at "don't add modules" we can close this PR here.