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
