[9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names (original) (raw)
Rémi Forax forax at univ-mlv.fr
Thu Apr 9 06:10:57 UTC 2015
- Previous message: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names
- Next message: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 "innernameindex: If C is anonymous (JLS §15.9.5), the value of the innernameindex item must be zero. Otherwise, the value of the innernameindex item must be a valid index into the constantpool table, and the entry at that index must be a CONSTANTUtf8info 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/javalang, jdk/test/java/lang/ Thanks! Best regards, Vladimir Ivanov
- Previous message: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names
- Next message: [9] RFR (S): Class.getSimpleName() should work for non-JLS compliant class names
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]