A facility for getting the current method's name

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Fri Sep 30 22:35:51 PDT 2011


Am 01.10.2011 03:49, schrieb Behrang Saeedzadeh:
> Hi Krystal,
>
> On Tue, Sep 27, 2011 at 8:35 PM, Krystal Mok<rednaxelafx at gmail.com>  wrote:
>> 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()
> This is very similar to what I am looking for. What I need is
> something like this:
>
> java.lang.invoke.MethodHandles.lookup().lookupMethod();
Is there a reason why you want it to be an operation/evaluation at runtime?
Because i don't see this at runtime. Am i missing something?
>> 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?
> Yes, AFAICT, it should be possible to get the current method's name
> without having to construct the (expensive) stack trace. I personally
> avoid suchlike operations ATM only because they're expensive.
>
> By the way, now that we're into it, it would be great if we have a
> standardized byte code enhancement library (e.g. ASM). I know, I know!
> I am asking for too much! :D
>
> Cheers,
> Behrang
>
>> 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.
>> Regards,
>> Kris Mok



More information about the jdk8-dev mailing list