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 <[email protected]> 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
