Indeed,
Cameron’s trick is pretty cool.  I have been using a similar trick for
a while now, except that when I wrote it, we didn’t have StackFrame support, so
it was all about dirty manual parsing of the stack trace.

However, my technique is different from Cameron’s in the following ways:

  • I don’t print the name of the variable.  Most of the time, I’m not
    tracing a variable (could be an array or the result of a method) and anyway,
    the name of the variable is not that important.
     
  • However, I use the trick to print the name of the class.  This is
    the most important part, in my opinion.  I can’t count the number of
    times where I painfully looked for a particular trace in my source code in
    order to remove it.  IDE’s make it a little easier to do that now, but
    they also have limits (like when the text happens to be i18n’ed and
    therefore, nowhere to be found in your *.java files).
     
  • And finally, I give my trace functions a very identifiable name, for a
    reason related to the previous point.  Using a name like "trace()" or
    "p()" makes it challenging to find all the places where you invoke the
    trace, so I typically use "ppp()".  You can’t type this by accident 🙂

All that being said, IDE’s make this kind of hack almost useless these days. 
For example, I have a template called "ppp" and all I need to do is type "ppp<space>"
at any moment to have the trace method automatically implemented with the class
name and everything else in it.

But it’s nowhere near as elegant as the trace walking.