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

[Eric McCorkle]

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 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 --------------
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