Clarifying record reflective support
Alex Buckley
alex.buckley at oracle.com
Tue Dec 3 17:06:28 UTC 2019
On 12/3/2019 8:39 AM, John Rose wrote:
> On Dec 3, 2019, at 8:31 AM, Alex Buckley <alex.buckley at oracle.com
> <mailto: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.
By "purpose", I mean the fundamental role of the attribute in the class
file. That's what JVMS 4.7 seeks to document by offering three lists. A
related but lower-level question is how much checking occurs at load
time versus reflection time.
Let me step back. I don't disagree with anything you say. I agree that
the second list, where Record lives because it's a Java language helper,
should be shallowly checked so that the deep stuff is left to reflection
(i.e. it could be "reflectively invalid" despite having passed class
file format checking). What I am trying to do is help Chris understand
the JVMS draft so he can ship in JDK 14 -- is there anything in section
4.7 of the draft that needs to be changed for JDK 14?
Alex
More information about the amber-spec-experts
mailing list