JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names

[David Holmes]

On 18/06/2015 7:56 AM, John Rose wrote:
> On Jun 17, 2015, at 6:27 AM, Jochen Theodorou <blackdrag at 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
>