Add support for Java Record deserialization

[TomaszGaweda]

Added support for record deserialization.

It is based on new Java's reflection methods, added with records. If record classes are not supported, code should follow normal path.

Difference from standard deserialization: properties are not set one-by-one, but caches in values array and then passed to all-arg constructor (always present in records)

[cowtowncoder]

I think we can avoid this one... see note below.

[TomaszGaweda]

53436e6

[cowtowncoder]

@TomaszGaweda GREAT contribution, thank you! I added some notes on changes needed; nothing major, just some streamlining.

One thing I'd need, aside from doing review, is CLA, from:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

(unless you have done one before; apologies if I missed it)

This is only needed once before merging the first contribution. Usually it's easiest to print, fill & sign, scan/photo, email to cla at fasterxml dot com.
Once I get it, I can merge the PR (pending code review etc)

Once again, big thank you for contribution this & let's get it merged in for 2.18(.0)!

[TomaszGaweda]

BTW. Should I somehow notice that RecordHelpers is based on Hazelcast's JavaRecordSerializer? I am Hazelcast's contractor, but this work is done privately. Hz code is under Apache 2 as well

[TomaszGaweda]

CLA signed and sent, CR comments addressed :)

[cowtowncoder]

I think RecordHelpers is general enough -- code in jackson-databind has detection code that is quite similar -- and used by many projects, so unless it's a clear-cut copy I probably would not add a reference there.

[TomaszGaweda]

Getting required method references is indeed generic enough - core logic had to be implemented here. I've rerequested review @cowtowncoder, thanks for your support!

[cowtowncoder]

Thank you @TomaszGaweda -- made some final tweaks (wrt since tags, add release notes), ready to go!

In future there may need to try to support annotation override (via jackson annotations extension), but for basic usage this should work nicely..

[cowtowncoder]

Hmmh. Unfortunately, didn't realize this but I don't think our Record test is running at all...

Will need to figure why, how to fix -- it appears to try to use JUnit 5, although all (other) tests are JUnit4

[darxriggs]

Here is some feedback on other variants of input data.

a) different order of fields in JSON than in Java record
input: {"object":{"Foo":"Bar"}, "message":"MOO"}
result: Failed to create an instance of jr.Java17RecordTest$Cow due to (java.lang.IllegalArgumentException): argument type mismatch

This should get fixed.

b) missing field in JSON
input: {"message":"MOO"}
result: Failed to create an instance of jr.Java17RecordTest$Cow due to (java.lang.IllegalArgumentException): wrong number of arguments

I am wondering how deserialization to records should handle missing data as the all-args record constructor requires all fields and if there should also be support for Optional like provided by jackson-modules-java8.

[cowtowncoder]

@darxriggs Could you file a separate issue for the problem with ordering? We definitely need more testing here. It can include part about missing values as well (no need for 2 issues).
As to missing values: should pass null, although this will be problematic for many cases like primitives.
These can be addressed incrementally; Optional isn't yet supported for anything else yet so it can be deferred.

[TomaszGaweda]

Thanks @darxriggs, I've included your feedback in a follow-up: #163

[cowtowncoder]

Ok, no, this simply does not work as-is. I will have to revert this for now.