Review request: update javac to properly output mandated parameters in MethodParameters attributes

John Rose john.r.rose at oracle.com
Tue Feb 12 22:22:22 PST 2013


On Feb 12, 2013, at 5:50 PM, Alex Buckley <alex.buckley at oracle.com> wrote:

> Per the new discussion in JLS 8.8.9 which appears in 8misc.pdf, it is possible for a _non-private_ inner member class to be instantiated by code in a totally different compilation unit, _compiled by a different compiler than compiled the inner member class_.

Since even private member classes have mandated names, it is possible to use reflection (with access control overrides as needed) to attempt to instantiate even private member classes.  This suggests to me that 'private' might not be enough isolation to allow complete freedom to the compiler.

On the other hand, non-member classes (anonymous and locals) do not have mandated bytecode names (there is always a $[0-9]+ component in the name), so it is reasonable to say none of the constructors and/or arguments need to have any mandated structure.

I realize that the JLS is one step away from reflective APIs, but there is a logical connection here, since the Core Reflection API claims to be able to (a) replicate legal member accesses, and (b) override access protection modifiers ('private' etc.).

> Hence the mandated parameter which allows all compilers to reify the immediately enclosing instance. But a _private_ inner member class can only be instantiated within the same compilation unit, so it's the compiler's choice how to reify the immediately enclosing instance in that case, and I believe javac has always used ACC_SYNTHETIC for that class's default ctor.

It's always used ACC_SYNTHETIC but that doesn't mean that ACC_MANDATED would be better for some bits of the puzzle.

— John

P.S. Do we still mandate names of certain inner class fields, such as 'this$NNN'?  The original motivation for this was to allow debuggers a somewhat easier time presenting compiler-generated data structures.

It's a stretch, but it might be reasonable to require that the names of the constructor parameters match the names of the concrete private class fields they initialize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130212/38b73102/attachment.html 


More information about the compiler-dev mailing list