Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

I have patch for a public API for this just about complete. I'm going to re-run unit tests tonight and then submit it. But I need some help. I quickly figured out that I can't just `hg diff` from the root directory, because of the whole "forrest" thing. Ick. So, is there a specific way that I n

Re: Classes on the stack trace

ome > infrastructure-inserted frames are hidden-away just for @CallerSensitive > methods which might be less optimal and not needed for normal methods. > > > Regards, Peter > > On 07/31/2013 01:11 AM, Nick Williams wrote: >> Quick question for those of you that

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

Quick question for those of you that know anything about @CallerSensitive... After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it finds the first method without @CallerSensitive. It only returns the caller of the caller. So,

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

annotated @CallerSensitive. In these cases, use of any new public >> API must use reflection (sudo code: If Java 8, use new public >> caller-sensitive API), so it needs code that it can pass a number into. >> >> Nick >> >> On Jul 30, 2013, at 7:17 AM, Peter Lev

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

that it can pass a number into. Nick On Jul 30, 2013, at 7:17 AM, Peter Levart wrote: > > On 07/27/2013 09:01 PM, Nick Williams wrote: >> All, >> >> In the last two months, there have been a number of discussions surrounding >> stack traces, Classes on the stac