Queries and patch for JDK-8034854: outer_class_info_index of synthetic class is not zero
alex.buckley at oracle.com
Wed Feb 19 11:13:09 PST 2014
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
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.
On 2/19/2014 4:34 AM, Jan Lahoda wrote:
> I have a few questions about JDK-8034854 and a possible patch/fix for
> it. The bug URL:
> 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:
> 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.
More information about the compiler-dev