Reflection APIs for records

[Remi Forax]

----- Mail original -----
> De: "Oliver Drotbohm" <odrotbohm at pivotal.io>
> À: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Samedi 18 Janvier 2020 15:54:42
> Objet: Reflection APIs for records


Hi Oliver,

> Hi all,
> 
> the Spring team is currently investigating integration with records in various
> parts of the framework like form binding in Spring WebMVC/WebFlux or object
> mapping in Spring Data. 

Thanks for doing this !

> Historically those features have worked with the
> PropertyDescriptor APIs adding a few tweaks here and there.
> 
> I was wondering whether you'd be willing to consider to expose
> PropertyDescriptors for record types so that they're effectively equivalents to
> a read-only property. I gave the Spring Framework abstraction around this a
> quick spin, plugging in a component that would create a synthetic
> PropertyDescriptor instance like this:
> 
> private static PropertyDescriptor toPropertyDescriptor(RecordComponent
> component) {
> 
>  try {
>    return new PropertyDescriptor(component.getName(), component.getAccessor(),
>    null);
>  } catch (IntrospectionException o_O) {
>    throw new RuntimeException("Invalid record definition!", o_O);
>  }
> }
> 
> This makes Spring Data object mapping work with records without any further
> changes. It also nicely mitigates between towards the different naming
> convention of the accessor methods in records.

Making a record a bean doesn't worth the pain in my opinion.
Making a record a bean is not free, you have a lot of compatibility tests to pass for mostly no gain.

A record is not only a class that exposes "properties" like a bean but it's also a class that expose how to marshall/unmarshall itself.
Seeing a record as a bean is likely to not be enough for existing libraries, as you said it will require tweaks.
So you are asking for a kind of compatibility layer that is not enough for most libraries, so either library maintainers will want full support so add more stuffs to the bean spec which is a huge No or will end up by using plain reflection, making the compatibility layer useless. 

We expect library maintainers to be able to directly integrate records quite easily, the fact that you are be able to integrate them in Spring Data confirm that we are on the right track on that point.

> 
> If those PropertyDescriptors were exposed by the reflection APIs in the JDK in
> the first place,  other libraries could automatically work with records out of
> the box and would not need similar - or at least less - additional code.
> Jackson, Hibernate, template engines, EL implementations etc.
> 
> Slightly less important but still very welcome would be explicit exposure of the
> record constructor so that we don't have to scan and potentially disambiguate
> the one to be used to create instances of those records.

If you mean providing a method getRecordCanonicalConstructor() in java.lang.Class with a code roughly similar to
  recordClass.getConstructor(Arrays.stream(recordClass.getRecordComponents()).map(RecordComponent::getType).toArray(Class[]::new));
we discuss about that and if I remember correctly defer that item saying we will see if people want that method or not :) 

> 
> Cheers,
> Ollie

regards,
Rémi