Review request: update javac to properly output mandated parameters in MethodParameters attributes (original) (raw)

Eric McCorkle eric.mccorkle at oracle.com
Wed Feb 13 08:06:32 PST 2013

For the purposes of this patch, can we go ahead and push it as is, so as to make M7, and possibly submit a one-liner at a later date if we decide to make private constructor's outer this mandated?

On 02/13/13 05:28, Maurizio Cimadamore wrote:

I agree with John - also, to my knowledge, all compilers out there treat private class/non-private class in the same way - i.e. by adding an extra constructor parameter for accepting the enclosing instance.

Maurizio On 13/02/13 06:22, John Rose wrote: On Feb 12, 2013, at 5:50 PM, Alex Buckley <alex.buckley at oracle.com_ _<mailto: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 ACCSYNTHETIC for that class's default ctor. It's always used ACCSYNTHETIC but that doesn't mean that ACCMANDATED 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 -------------- A non-text attachment was scrubbed... Name: eric_mccorkle.vcf Type: text/x-vcard Size: 303 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130213/a1641eed/eric_mccorkle.vcf

More information about the compiler-dev mailing list