Reflection APIs for records
brian.goetz at oracle.com
Sat Jan 18 16:20:45 UTC 2020
> 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.
Exposing them directly in this way is problematic, as PropertyDescriptor
is in the java.beans module and reflection is in java.base. This
argument wouldn't apply to, say, a constructor/factory in PD that took a
RecordComponent. On the other hand, if the implementation is as simple as
return new PropertyDescriptor(component.getName(), component.getAccessor(), null);
then I'm not quite sure how much this buys? You still have to be aware of records.
> 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.
By this, you mean a reflective method to get the _canonical_ constructor, rather than grovelling through the list of constructors? This is easy enough, but on the other hand, doing it by hand is also fairly simple: this is
More information about the amber-dev