Clarifying record reflective support
alex.buckley at oracle.com
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
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