Queries and patch for JDK-8034854: outer_class_info_index of synthetic class is not zero

[Alex Buckley]

It would make sense to consider the full range of reasons why these 
auxiliary classes are generated. You indicated one reason - tags for 
accessing private ctors - and it makes sense to generate a "true" 
anonymous class there (outer_class_info_index=0, inner_name_index=0). 
But perhaps other reasons would justify auxiliary classes with 
meaningful "owners" - again, your word - and there it would be sensible 
to consider them as member classes rather than anonymous classes.

Alex

On 2/20/2014 3:11 AM, Jan Lahoda wrote:
> Hi Alex,
>
> Thanks for the comments.
>
> I was briefly considering filling some inner_name for the synthetic
> classes, but using zeroing outer_class_info_index seemed somewhat
> cleaner, safer (no risk of name clashes or misinterpretation of the
> name) and simpler. But if generating an inner_name for the synthetic
> classes would be (strongly) preferred, I can investigate it.
>
> Jan
>
> On 02/19/2014 08:13 PM, Alex Buckley wrote:
>> Hi Jan,
>>
>> The requirement that outer_class_info_index must agree with
>> inner_name_index w.r.t. an anonymous class was added in JVMS7 because we
>> saw class files where they disagreed and it simply made no sense. The
>> requirement was conditioned on 51.0 class files because we didn't want
>> to break pre-7 class files with insensible InnerClasses.
>>
>> The auxiliary classes generated by javac appear to have a meaningful
>> "owner" - your word - so it would seem appropriate to have a non-zero
>> outer_class_info_index. Just generate a random name for
>> inner_name_index. (The 4.7.6 text assumes the "original simple name" can
>> be derived from source code, but that's not applicable for synthetic
>> classes.) This change could reasonably affect all target levels, since
>> no-one should be relying on the value of inner_name_index for these
>> auxiliary classes.
>>
>> OTOH, your proposal to represent the auxiliary classes as true anonymous
>> classes in InnerClasses is attractive because it exposes even less
>> information than at present. This change could reasonably affect all
>> target levels too, since no-one should be relying on the value of
>> outer_class_info_index for these auxiliary classes.
>>
>> Alex
>>
>> On 2/19/2014 4:34 AM, Jan Lahoda wrote:
>>> Hello,
>>>
>>> I have a few questions about JDK-8034854 and a possible patch/fix for
>>> it. The bug URL:
>>> https://bugs.openjdk.java.net/browse/JDK-8034854
>>>
>>> The problem is that while JVMS 7, 4.7.6. (The InnerClasses Attribute)
>>> mandates that:
>>>   If a class file has a version number that is greater than or equal to
>>>   51.0, and has an InnerClasses attribute in its attributes table, then
>>>   for all entries in the classes array of the InnerClasses attribute,
>>>   the value of the outer_class_info_index item must be zero if the value
>>>   of the inner_name_index item is zero.
>>> javac in some cases produces non-zero "outer_class_info_index" even if
>>> "inner_name_index" is zero. This happens for synthetically generated
>>> auxiliary classes. These classes are generated for a number of reasons,
>>> for example to be used as tags when accessing private constructors. The
>>> synthetic classes internally have an empty name, so the generated
>>> "inner_name_index" is zero, but their owner is a class, so they get the
>>> non-zero "outer_class_info_index".
>>>
>>> I've sketched out a simple fix for this problem, which ensures that
>>> "outer_class_info_index" is zero for classes that have empty name:
>>> http://cr.openjdk.java.net/~jlahoda/8034854/webrev.00/
>>>
>>> After this change, the generated synthetic classes look a lot like
>>> anonymous classes defined in an initializer of the given class (based on
>>> the InnerClasses attribute and the EnclosingMethod attribute). That
>>> seems reasonable to me.
>>>
>>> My questions are:
>>> -does the fix above make sense?
>>> -the change affects all target levels. It seems to me that the new
>>> behavior makes sense even for pre-7 classfiles, but I'll gladly limit
>>> the new behavior to only some minimal target level if desired.
>>>
>>> Any comments welcome.
>>>
>>> Thanks,
>>>     Jan