On 15/06/2013 19:33, Nick Williams wrote:
:
Looking at Throwable.java and Throwable.c, getStackTrace() ultimately calls
JVM_GetStackTraceElement. Looking at jvm.c from Java 6 (I can't find
JVM_GetStackTraceElement in newer versions of Java), JVM_GetStackTraceElement
calls CVMgetStackTraceElement.
CVMgetStackTraceElement, in turn, then gets a copy of the native version of the
Class object and uses it to populate the StackTraceElement's data. This leads
me to believe that the task of adding a getElementClass() method to
StackTraceElement would be as simple as:
1) Adding a new constructor to StackTraceElement to preserve backwards
compatibility, with the Class being null by default.
2) Add the getStackTraceElement() method and backing private field.
3) Add a CVMID_fieldWriteRef call to set the class to the backing private field.
I'm sure there are some idiosyncrasies I'm missing here, but overall this seems
like a pretty trivial change. What do people think? Can this be worked in? .NET
has had this ability since .NET 1.1 with the StackFrame class [2] and the
StackTrace [3], which contains StackFrames. It provides more than just the
Class (Type in .NET), it also provides the Method (MethodBase in .NET). It
would greatly improve the efficiency of certain tasks not only in Log4j, but
also in many other projects that I have found using getCallerClass() for the
same purpose.
Here's a discussion from last year on this topic:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011665.html
-Alan.
