[ 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 <[email protected]
<mailto:[email protected]>> 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
