A facility for getting the current method's name

[Krystal Mok]

Yeah, I'm sure there are a lot of ways one can implement this feature. It's
just the matter of whether or not the feature should be supported by the
core libs.

I can even imagine (ab-)using an annotation processor to pull it off.
Something that looks like:

public class Foo {
  public void bar() {
    @CurrentMethodName
    String __method__ = null; // suppose this local variable is generated by
some refactoring tool
  }
}

where @CurrentMethodName is a ElementType.LOCAL_VARIABLE +
RetentionPolicy.SOURCE annotation, and the null assignment gets replaced to
the actual value, by a custom annotation processor at compile time.

Regards,
Kris Mok

On Wed, Sep 28, 2011 at 12:12 PM, Sebastian Sickelmann <
sebastian.sickelmann at gmx.de> wrote:

> Am 27.09.2011 12:35, schrieb Krystal Mok:
>
>  Hi Behrang,
>>
>> This reminds me of how people were looking for a "current class literal",
>> something like this:
>>
>> public class Foo {
>>   public static void main(String[] args) {
>>     // don't want to hard code "Foo.class" here
>>     String name = Foo.class.getName();
>>   }
>> }
>>
>> and now that JDK7 is out, they've got a new toy that gives them exactly
>> that:
>>
>> java.lang.invoke.**MethodHandles.lookup().**lookupClass()
>>
>> It's not mean't to be fast when used like this, though.
>> The same with what you're looking for, but you've already got backtrace
>> which gives you the correct semantics, just not fast enough, right?
>>
>> On Mon, Sep 26, 2011 at 7:31 PM, Behrang Saeedzadeh<behrangsa at gmail.com**
>> >wrote:
>>
>>  Sean, Mario,
>>>
>>> I am looking for something like JavaScript's arguments.callee.name or
>>> Ruby's __method__. AFAIK, accessing the current method's name is a
>>> very cheap operation in JS and Ruby while creating a stack trace is a
>>> moderately expensive operation in Java.
>>>
>>
>> They don't seem to be expensive in JavaScript or Ruby because those
>> languages didn't have fast implementations. Once they do (as the current
>> JS
>> engines and JRuby/Rubinius), this kind of reflective operations will show
>> their cost.
>>
> I think that this can be done at compile-time where instead of the method
> call
> a constant will be inserted into the bytecode of the class. I don't see
> any dynamic resolve in here. The main problem i see is how to specify this
> in java syntax.
>
> Just replacing the INVOKESTATIC (lets say ActualMethod.getName()) into an
> LDC
> breaks the common pattern how a static Methodcall in compiled to bytecode.
> Or
> are there any places in javac where such a replacement for special cases is
> already done?
> And a new Keyword for just inserting the methodname is a bit to big!?
> Maybe the ActualMethod.getName() should be marked with a annotation
> @Constant-Replace
>
> If i want to check if this is feasible i would write a small
> ClassFileTransformer
> that exchanges any static calls of ActualMethod.getName() to the LDC at
> loadtime.
> I think this is the other place where it can be done. Unfortunately i don't
> see that this
> can be done on jvm in general, cause all those other languages that are
> running
> on the jvm don't need such a feature. So i think javac or some custom post
> processing
> would be the best place to do this.
>
> -- Sebastian
>
>> Regards,
>> Kris Mok
>>
>
>