Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

Ralph Goers ralph.goers at
Tue Mar 14 06:03:46 UTC 2017

I have fixed the test that located the caller’s Class object with StackWalker. It is now faster than Reflection.getCallerClass() was. 

I have also created a test to get the Caller’s StackTraceElement with StackWalker. It is now much, much faster than walking the Throwable was in Java 8, so that will be a definite incentive for Log4j to use it.

Sorry for the misinformation on these but thanks for giving me help on improving the tests.


> On Mar 13, 2017, at 3:38 PM, Mandy Chung <mandy.chung at> wrote:
> Hi Ralph,
> I have filed <> for Throwable::getStackTrace performance regression.
>> On Mar 13, 2017, at 1:57 PM, Daniel Fuchs <daniel.fuchs at> wrote:
>> Hi Ralph,
>> On 13/03/17 19:06, Ralph Goers wrote:
>>> OK - I will do that when I fix the other bug.  But if you can suggest some other way to bail out of the loop after I have found the correct StackFrame that would help as well.
>> I'd suggest using filter + findFirst, possibly with a
>> statefull Predicate<StackFrame> - depending on the logic
>> needed to identify the frame you want to return.
>> That's what we do in java.util.logging - where we walk
>> until we find a logger implementation frame, and then
>> continue walking until we find a frame that no longer
>> belong to the logging infrastructure.
> As Daniel said, we suggest to walk the stack from the most recent frame and stops when the logging implementation frames are skipped.  
> This is where java.util.logging does its filtering that you can reference:
> <>
> Mandy

More information about the core-libs-dev mailing list