Looks good.
Minor nits:
* in getRecordComponents there are some utterings of "true", "false" and
"null" which are not surrounded by a {@code } block.
* any reason as to why the j.l.Record class is not cached in a static field?
On the CSR:
* "These arose when finalizing and completing the runtime CSR" - please
add a link to the CSR
* "It's direct superclass must be |java.lang.Record,| and" --- s/it's/its
* "in it's specification ... guaranteed --- s/it's/its and also
s/guaranteed/guarantee
* "We thought it kinda nice to be able to avoid returning null, but in
hindsight" - "While initially it was considered desirable to avoid
returning null, in hindsight"
Added myself as reviewer
Thanks
Maurizio
On 09/12/2019 12:51, Chris Hegarty wrote:
This is a review request for a change to add a clarification to the
record related core reflection methods, that specifies what it means to
be a record class and access to the record components. Discussed
originally over on amber-spec-experts [1]
I expanded the existing record reflection test and also added a new test
( with the original record push bug no. ) to cover security manager
checks ( since I couldn't find an existing test ).
Bug: https://bugs.openjdk.java.net/browse/JDK-8235550
CSR: https://bugs.openjdk.java.net/browse/JDK-8235583
Webrev: https://cr.openjdk.java.net/~chegar/8235550/webrev.00/
-Chris.
[1]
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001840.html
