Clarifying record reflective support

[Alex Buckley]

On 12/3/2019 6:24 AM, Chris Hegarty wrote:
> At least from the JVM side of things, one could lean on the JVMS,
> Section 4.1 “The ClassFile Structure”. While the draft records JVMS does
> amend various sections and subsections of Chapter 4, it does not touch
> section 4.1.  Reading between the lines, I think one way of ensuring the
> well-formedness of the Record attribute would be to add a reference to
> it from the top-level `attributes[]` format, e.g.
> 
>    "If a Java Virtual Machine implementation recognizes class files
>     whose version number is XX.xx or above, it must recognize and
>     correctly read the Record (§4.7.xx) attribute found in the attributes
>     table of a ClassFile structure of a class file whose version number
>     is XX.xx or above."
> 
> This is similar to the Signature, and a few other, attributes.
> 
> If we had this, then the implementation could rely on simply the
> presence of a Record attribute, and no further checking would be
> necessary.

http://cr.openjdk.java.net/~gbierman/jep359/jep359-20191125/specs/records-jvms.html#jvms-4.7 
already specifies Record as an attribute similar to other 
language-oriented attributes such as Exceptions and Signature: "critical 
to correct interpretation of the class file by the class libraries of 
the Java SE Platform". Record must therefore be format-checked eagerly 
(at class load time) rather than lazily (at reflection time).

For example, if the Record.components[i].attributes table contains a 
Signature attribute, then that's fine per Table 4.7-C; but if said table 
contains a Code attribute, then the overall Record attribute is 
malformed, and I would expect a ClassFormatError as I would for a 
malformed descriptor in Signature. (I don't wish to rat-hole on whether 
HotSpot actually checks Signature so deeply. The purpose of Signature is 
clear, and aligned with the purpose of Record, and purpose is what 
should drive depth-of-check.)

Alex