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

[Rémi Forax]

Hi David,
The problem is that j.l.i.MethodType.toString uses getSimpleName and j.l
i.WrongMethodTypeException uses MethodType.toString.

So if getSimpleName returns a blank string, you destroy the debuggability of any invokedynamic/methodhandle calls.

regards,
Rémi 

Le 9 avril 2015 04:52:15 CEST, David Holmes <david.holmes at oracle.com> a écrit :
>Hi Vladimir,
>
>On 9/04/2015 1:41 AM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/jdk
>> http://cr.openjdk.java.net/~vlivanov/8057919/webrev.00/hotspot
>> https://bugs.openjdk.java.net/browse/JDK-8057919
>>
>> 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 "" ?
>
>> 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