On 12/3/2019 8:39 AM, John Rose wrote:
On Dec 3, 2019, at 8:31 AM, Alex Buckley <alex.buck...@oracle.com
<mailto: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.
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
