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.hol...@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
