question about java.lang.reflect.RecordComponent API

[Vicente Romero]

Hi,

I have got some comments in the CSR [1], that affect the API of 
java.lang.reflect.RecordComponent. As I have also received comments on 
the opposite direction I think this deserves a broader discussion. Some 
context I have added a toString method to RecordComponent after a review 
comment. The proposal was to make the method similar to 
java.lang.reflect.Field::toString so the current spec of the method is:

/** * Returns a string describing this record component, including * its 
generic type. The format is: the generic record component type, * 
followed by a space, followed by the fully-qualified name of the * 
record class declaring the record component, followed by a period, * 
followed by the name of the record component. * * @return a string 
describing this record component, including its * generic type */

On the other hand I got another suggestion to make the method more 
similar to java.lang.reflect.Parameter, so removing the record class 
declaring the component from the resulting string. Which direction do we 
want to go? Consider that there is already a similar method, 
::toGenericString, with spec:

/** * Returns a string describing this record component, including * its 
generic type. The format is: the generic record component type, * 
followed by a space, followed by the fully-qualified name of the * 
record class declaring the record component, followed by a period, * 
followed by the name of the record component. * * @return a string 
describing this record component, including its * generic type */

So any decision here should affect both. In addition I got another 
suggestion to add a new method to j.l.r.RecordComponent: 
`getDeclaringRecord` on the lines of 
j.l.r.Parameter::getDeclaringExecutable. Comments?

Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8233436

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191105/d3b15d19/attachment.html>