A facility for getting the current method's name
Behrang Saeedzadeh
behrangsa at gmail.com
Fri Sep 30 18:49:18 PDT 2011
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();
> 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