Clarifying record reflective support
john.r.rose at oracle.com
Tue Dec 3 16:39:51 UTC 2019
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts