RFR (S): Class.getSimpleName() should work for non-JLS compliant class names
david.holmes at oracle.com
Thu Apr 9 06:27:33 UTC 2015
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
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?
> 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:
>>> 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
>> 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
>>> 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).
>>> Testing: regression test, jck-runtime/java_lang, jdk/test/java/lang/
>>> Best regards,
>>> Vladimir Ivanov
More information about the hotspot-dev