On Dec 3, 2019, at 9:06 AM, Alex Buckley <alex.buck...@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.buck...@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
