Clarifying record reflective support

[Alex Buckley]

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