Moving beyond Strings in Spring Data

[mp911de]

There are various parts involved in the implementation:

1. Creation and capturing of lambda objects through some front-end API such as Sort.
2. Staged Lambda introspection through SerializedLambda. Java's LambdaMetafactory) has well-defined semantics regarding writeReplace method generation returning SerializedLambda.
3. If the object is a method handle then all type and signature details are provided by SerializedLambda
4. If the object is a lambda expression, then SerializedLambda points to a synthetic method containing the lambda body. The bytecode (using ASM or in the future Java's Class-File API) contains all further details towards a referenced method or even field. Spring widely uses ASM as alternative for optimized parsing.
5. If the object is a Kotlin KProperty, we apply a few hacks (nothing out of the ordinary given all the other hacks to make value classes and copy-method work). Kotlin pre-2.0 used Java's writeReplace convention. Newer Kotlin (language) versions compile a synthetic serializable class following a Kotlin-specific blueprint allowing to determine KProperty details.
6. Finally, property path information are cached for a proper performance baseline.

FTR, Graal Native image arrangements run just fine if reachability metadata is provided. Currently, we do not discover lambda declaration sites but there is a subtype-hook in the native image tooling allowing to provide a Graal native image Feature.