Chris West posted a blog entry called "Java stacktraces straw man," about a project called LineNos, which changes the traditional stack trace dump from Java to something more readable and informative, including a reference to the method that caused the exception.

To use it, you install a java agent on the java invocation, and then you get better and more informative stack traces. I've never had to use anything like it, but I think it would have saved me some time irregardless.

Cool stuff.

Actually the bigger problem with stack traces is that there is no frame id so consecutive dumps cannot be reliably used to indicate whether a thread is hung/busy processing the same request or another request with a similar call path which is pretty normal in Java EE if not most apps.

http://williamlouth.wordpress.com/2009/02/08/better-java-thread-stack-trace-dumps/

http://williamlouth.wordpress.com/2009/10/06/java-call-stack-problem-analysis-simplified/

And with thread/frame ids you can do much better performance investigation.

http://williamlouth.wordpress.com/2010/08/17/low-latency-monitoring-w-probes-metrics/

irregardless is a double negative...

regardless - without regard

ir- is also used to negate.

So that makes it twice as negative, or does it make it half as negative? Or does it negate the negative?

So that makes it twice as negative, or does it make it half as negative? Or does it negate the negative?

I don't disagree with you.