Hi Ralph,
On 14/03/2017 06:03, Ralph Goers wrote:
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.
This is good news :-) Thanks for sharing it!
Sorry for the misinformation on these but thanks for giving me help on
improving the tests.
No problem! Thanks for taking the time to test this new API and
providing feedback. This is the only way we can improve!
best regards,
-- daniel
Ralph
On Mar 13, 2017, at 3:38 PM, Mandy Chung <[email protected]
<mailto:[email protected]>> wrote:
Hi Ralph,
I have filed https://bugs.openjdk.java.net/browse/JDK-8176593 for
Throwable::getStackTrace performance regression.
On Mar 13, 2017, at 1:57 PM, Daniel Fuchs <[email protected]
<mailto:[email protected]>> 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
Mandy
