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

[David Holmes]

Hi Vladimir,

On 10/04/2015 12:51 AM, Vladimir Ivanov wrote:
> 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.

This change seems fine to me, but I think John may prefer to see 
getSimpleName implemented such that it always returns the name from the 
innerclass attribute. (Though perhaps with caching if performance is a 
concern?)

>>> 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.

True, but it does refer to source code: "represents the original simple 
name of C, as given in the source code from which this class file was 
compiled. " which seems misplaced as we're discussing classes for which 
there is no source code as such.

Anyway it just flags to me that perhaps these Class methods need to be 
generalized a bit given the support for non-Java languages on the JVM. 
But that's for core-libs folk to decide.

Thanks,
David

> 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