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

[David Holmes]

Hi Remi,

On 9/04/2015 4:10 PM, Rémi Forax wrote:
> 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.

Okay, so an alternative there is for MethodType.toString to not use 
getSimpleName :)

More seriously perhaps things like getSimpleName need to be re-specified 
to account for classes coming from other than Java source code? Even the 
INNERCLASSES_Attribute associates the name with Java source code: 
"original simple name of C, as given in the source code from which this 
class file was compiled". And what is a "simple name"? It should be the 
most basic name given to a class without any prefix that indicates an 
enclosing type or containing package - but if non-Java-language-names 
are allowed how can you recognize such a prefix?

Cheers,
David

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