The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Obtaining Scoped Method Signature

Hello, all -

I just finished a busywork project at work, but I'm wondering if I could have done this better and thought I'd ask for the community's thoughts. The project was to update logging information by prepending both the class and method name to all logged messages. Our logging API currently takes a String, a Locale and possibly an Exception, and I was told not to update that as it's being phased out over the course of the next year.

I did this in two parts. The class name is easily gotten through various reflection methods, but I wound up having to hand-code the signature of the method the call occurred in. It wasn't a big deal, but I have a STRONG suspicion that there's a better way to do that in Java.

Does anyone have any pointers on how this better way might actually be accomplished? To be clear, I'm looking to extract the signature of the method whose scope the logging call is in - I'm not looking for a general listing of method signatures (which is a simple API call).

BrotherBeal Send private email
Friday, June 20, 2008
A quick google search came up with the suggestion of throwing and catching an exception and examining it, or just creating a new Throwable object and querying the backtrace from it.
Mark Bessey Send private email
Friday, June 20, 2008
People have been known to use aspects for this (google "AspectJ"), but perhaps a simpler way in this case would be to use javassist, a simple run-time compiler + bytecode weaver.
For true
Friday, June 20, 2008
Weaving is probably the best solution. Its fairly expensive to extract the stacktrace (Thread.currentThread().getStackTrace()[0]), and logging should be very cheap.

I tend to be pragmatic and I'd say that if the class is large enough that you need the method signature, you have bigger problems.
Benjamin Manes Send private email
Friday, June 20, 2008
Also, the stack trace approach may not be 100% reliable..

From the documentation of Throwable#getStackTrace :

"Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method. Generally speaking, the array returned by this method will contain one element for every frame that would be printed by printStackTrace."
For true
Saturday, June 21, 2008
All -

Thanks for the tips. From what I've heard, it seems like the "hardcoded" way was the best. Our codebase is prohibitively large to use AOP for this (we use Spring for our base infrastructure, but to add aspects for this would require the addition of nearly 2000 other classes to Spring config). The stacktrace way is also unlikely to help - stack traces don't come for free, and we run in a virtualized environment where stack traces aren't always accurate.

It's unfortunate that there isn't some simple way to access this information in code, (maybe something like Method.getCurrentMethod()) but then that's probably not something that is needed frequently enough to warrant addition to the language and VM spec. Thanks!
BrotherBeal Send private email
Monday, June 23, 2008
> but then that's probably not something that is needed frequently enough to warrant addition to the language and VM spec.

It is needed frequently enough to warrant an addition to the language and JVM spec. Unfortunately, that is not always regarded as a sufficient condition for additions ;o)

Good luck!
For true
Tuesday, June 24, 2008
Benjamin, you are right that Thread.getStackTrace() is very expensive. I was doing some performance measurements on a J2EE app using JProbe and 2 seeming innocuous calls to it [they didn't even get logged] out of all the executed source lines were burning like 5% of the resources. I was shocked at how expensive that call was. It was an easy win cutting those 2 trash lines.
Tuesday, June 24, 2008

Amusingly enough, I just found this exact problem. One of my coworkers decided he had to write his own logging facade and swore it was extremely performant (despite being fully synchronized). On profiling, after many requests and having caused deadlocks in production, his proof that synchronizing wasn't the biggest problem showed that instead it was from dumping the stack on every call. He's yet to acknowledge that tidbit, so I'm awaiting the long battle to get it fixed...
Benjamin Manes Send private email
Friday, June 27, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz