[9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names

[Vladimir Ivanov]

David, thanks for the feedback!

Updated webrev:
   http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk
   http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot

I restored original logic and call into VM only if it fails.

>> The logic to compute simple name (Class.getSimpleName()) for
>> inner/nested/local classes is tightly coupled with Java naming scheme
>> and sometimes fails for classes generated from non-Java code.
>
> Meta-question: if this is non-Java code then what does/should
> "simpleName" even mean? "Returns the simple name of the underlying class
> as given in the source code." If there is no (java) source code does
> this have any meaning? Should it return "" ?
My reading of the JVMS is that InnerClasses attribute can be freely used 
by non-Java compilers to store simple names for classes they generate. 
The current wording for inner_name_index doesn't mention Java language.

Best regards,
Vladimir Ivanov

>> Instead of parsing class name and try to extract simple name based on
>> JLS rules, the fix I propose is to use InnerClasses attribute from the
>> class file. Simple name is already recorded there.
>  >
>> JVMS-4.7.6: The InnerClasses Attribute
>> "inner_name_index: If C is anonymous (JLS §15.9.5), the value of the
>> inner_name_index item must be zero. Otherwise, the value of the
>> inner_name_index item must be a valid index into the constant_pool
>> table, and the entry at that index must be a CONSTANT_Utf8_info
>> structure (§4.4.7) that represents the original simple name of C, as
>> given in the source code from which this class file was compiled."
>>
>> Since I consider backporting the fix into 8u60, I'd like to hear
>> opinions about backward compatibility of such change.
>>
>> As an alternative solution, I can restore original logic and consult
>> InnerClasses attribute when class name parsing logic fails.
>
> I think I'd prefer to see the VM call only used as a fallback if the
> regular parsing fails. That would prevent any compatibility issues for
> the 8u backport (ignoring tests that deliberately generate invalidly
> named classes).
>
> Thanks,
> David
>
>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov