Clarifying record reflective support

[Brian Goetz]

[ overall: agree that we've got the right thing for now, that reflection 
isn't the right place to specify class file formats, etc ]

For the future: I agree that there is not a right place for specifying 
the proper translation of language concepts (class, interface, enum, 
record, etc) into classfiles.  For some of these, it's "obvious" (e.g., 
ACC_INTERFACE), but as we add new language constructs like records, 
while simultaneously running out of ACC bits, it gets less obvious.  The 
"right" place for this would be a "translation spec", but we are 
understandably reluctant to risk over-specifying the translation mechanism.

A good example of where we might get ourselves into trouble is how, say, 
we translate the accessibility of a private nested class; today we 
translate this to a package-private class, but we wouldn't want to have 
committed to that for all times -- if we could translate it to actual 
private, that would be better.

Specifying all of this for its own sake seems like borrowing trouble.  
But, I think there's a subset of this, which is really what Dan is 
getting at, which is: "I'm a language compiler and I want to generate 
classes that interoperate nicely with reflection/javac, what do I have 
to do to not be a 'broken tool'?"

On 12/3/2019 1:52 PM, John Rose wrote:
> On Dec 3, 2019, at 10:36 AM, Dan Smith <daniel.smith at oracle.com 
> <mailto:daniel.smith at oracle.com>> wrote:
>>
>> My general feeling about the reflection API is that it could do a 
>> better job of specifying behavior for the full space of class files, 
>> not just those produced by javac. I wouldn't mind a lot more 
>> discussion about class file artifacts like attributes. The API 
>> javadoc seems like the best place for this. But the status quo is to 
>> be vague, and if we're going to raise the bar on precision in 
>> reflection API documentation, that's best handled as an independent, 
>> holistic effort.
>
> I agree, subject to priorities and who has time to work on what.
> Let’s file a tracking issue for this, shall we?
> That’s probably the best way to stabilize a consensus.
>
> — John

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