RFR [14] 8235550: Clarify record reflective support specification

[Maurizio Cimadamore]

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