On Dec 3, 2019, at 8:31 AM, Alex Buckley <alex.buck...@oracle.com> wrote: > > 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.)
As I argued in my just-sent mail, such purposes split into two parts: The purposes necessary for bytecode execution, and those necessary for reflection. This leads to a middle ground of “reflectively invalid” attributes which can nonetheless pass class file loading. I don’t view it as a bug that checks on Signature are deferred to reflection. I would view it as a spec. bug if the JVM were required to vigorously check such things as a condition for bytecode execution. — John
