Reflection APIs for records

[Brian Goetz]

> 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

     getConstructor(Stream.of(clazz.getRecordComponents()).map(RecordComponent::getType).toArray(Class[]::new)));

(or similar).