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

[Ralph Goers]

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.

Ralph

> On Mar 13, 2017, at 3:38 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Ralph,
> 
> I have filed https://bugs.openjdk.java.net/browse/JDK-8176593 <https://bugs.openjdk.java.net/browse/JDK-8176593> for Throwable::getStackTrace performance regression.
> 
>> On Mar 13, 2017, at 1:57 PM, Daniel Fuchs <daniel.fuchs at oracle.com> 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:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ddf8af0e536a/src/java.logging/share/classes/java/util/logging/LogRecord.java#l696 <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/ddf8af0e536a/src/java.logging/share/classes/java/util/logging/LogRecord.java#l696>
> 
> Mandy