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

David, John, thanks for review! Best regards, Vladimir Ivanov On 4/14/15 3:47 AM, David Holmes wrote: On 14/04/2015 3:39 AM, Vladimir Ivanov wrote: John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jd

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

On 14/04/2015 3:39 AM, Vladimir Ivanov wrote: John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Looks good - thanks. David Best

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

It's good. Nice cleanup. — John On Apr 13, 2015, at 10:39 AM, Vladimir Ivanov wrote: > > John, David, thanks for the feedback! > > What do you think about the following version: > http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk >

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

John, David, thanks for the feedback! What do you think about the following version: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.02/hotspot Best regards, Vladimir Ivanov On 4/10/15 10:15 PM, John Rose wrote: On Apr 9, 2015,

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

David, thanks for the feedback! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/jdk http://cr.openjdk.java.net/~vlivanov/8057919/webrev.01/hotspot I restored original logic and call into VM only if it fails. The logic to compute simple name (Class.getSimpleName()) fo

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

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. Debugga

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

On Apr 8, 2015, at 7:52 PM, David Holmes wrote: > > 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

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

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 c

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

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

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

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

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

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 s