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

Reply via email to