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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Apr 9 14:17:27 UTC 2015

On 4/9/15 9:10 AM, 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.
Debuggability is a different story. MethodType.toString() can produce 
ambiguous description, since it doesn't print all the details about the 

Right now, if a MethodType refers to a problematic class, 
MethodType.toString() throws an InternalError("Malformed class name").

Best regards,
Vladimir Ivanov

> 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

More information about the core-libs-dev mailing list