On 18/06/2015 7:56 AM, John Rose wrote:
On Jun 17, 2015, at 6:27 AM, Jochen Theodorou <blackd...@gmx.org> wrote:
I did not expect that the outer class is not set for Local and Anonymous
classes. I would have thought that the enclosing method is the only difference.
A bit of history (which can be found in the JVMS itself): The EnclosingMethod
attribute came in 5.0, years after the InnerClasses attribute in 1.1. So the
IC's will be properly categorized without the help of EnclosingMethod.
As the JVMS says, the function of the "outer_class_info_index" field, for some
inner class E.C, is to report the identity of the class E; it is not to report a class
that lexically encloses C. If a class C is not a member of some E (because local or
anonymous) it must have a null outer class.
(@David H: The JVMS also says that the "inner_name_index" field must be 0 for anonymous
and a valid Utf8 reference for non-anonymous. It claims that this Utf8 reference must represents
"the original simple name of C, as given in the source code from which this class file was
compiled." In the case of Java, that original simple name cannot be a null string, or any
other goofy string. But, heh heh, that does not constrain languages other than Java. Common
Lisp—to name one example—allows identifiers of zero length, spelled with appropriate quotes in
source code.)
So Class.isAnonymousClass() can only be fully correctly implemented in
the VM by checking the inner_name_index.
Though really what concerns me more here is that java.lang.Class, which
is purportedly specific to the Java Programming Language, is being
required to accommodate non Java language classes in methods that were
defined for the Java programming language. That seems wrong to me.
Obviously we need something to allow examination/interrogation of such
classes, but that should either be done by a different Class or by new
methods in Class specifically intended to handle bytecode semantics as
opposed to Java language semantics.
Cheers,
David
That's surprising to me.... but actually there is even code for this. And I
found the bug as well... So thanks for the help
Jochen, it sounds like an extra-picky ASM validator could have helped you debug
this. Having a class with null name and a non-null outer class is logically
invalid, though (I think) the JVMS accepts it.
— John