Clarifying record reflective support

[John Rose]

On Dec 3, 2019, at 9:06 AM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> 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?


No, it’s good!  What I’ve written in this thread is to document some of the reasons
*why* it’s good enough, and doesn’t need an “overkill” treatment of error detection
and reporting.

After reading it one more time, I have one more marginal note about the JVMS
draft:  It speaks of “record components” as entities to which the Record attribute’s
name and descriptor fields must correspond to.  But the JVMS doesn’t define
what is a “record component”.  And *that’s just fine*.  The JVMS sometimes talks
about correspondences holding between parts of the classfile and entities outside
of its purview.  This is arguably a “spec smell”, but it also serves as useful guidance,
even necessary guidance, to tool implementors.

Ship it!

On Dec 3, 2019, at 8:57 AM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
>> The javadoc is relatively silent about reflectively invalid class files,
>> but don’t take that as evidence that failure is impossible.
> 
> The four paragraphs above suggest that the API spec should document "low-level errors" about invalid class files (that is, invalid according to deep, reflection-time, checks). The next paragraph, however, suggests that the API spec doesn't need to document such errors/failure modes:

I’m trying to take account of both sides of the question, but in the
end I like the status quo of being vague about obscure error modes
in reflection, especially those caused only by broken tools.  Dan is
saying the same thing, I think:  We *could* work very hard and
document more (all?) of the failure modes for *all* the API points,
but we *shouldn’t* single out Record for the overkill treatment.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191203/99a95e85/attachment.html>