Clarifying record reflective support

[John Rose]

On Dec 3, 2019, at 8:31 AM, Alex Buckley <alex.buckley at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191203/ea07fb7f/attachment.html>