Clarifying record reflective support

Alex Buckley alex.buckley at
Tue Dec 3 16:31:31 UTC 2019

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. 
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.)


More information about the amber-spec-experts mailing list