Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is
described as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
.skip(2)
.findFirst()).orElse(Thread.currentThread().getClass());
... the .orElse is presumably meant for the case when getCallerClass()
is called directly from within Thread.run() method right? In that case
Thread's implementation class is presented as the one doing the
invocation of Thread.run(), which seems logical.
But what about if getCallerClass() is called from a method that has been
invoked from native code via JNI in a newly attached thread that was not
started in Java (like the main method)? We will also get the Thread's
implementation class as the caller. Is this still logical?
What would it be if getCallerClass() returned just Optional<Class<?>>
and was left to the user to decide what to do in corner cases when there
is no Java caller?
So returning java.lang.Class objects is safe now there is jigsaw to
enforce isolation when doing reflection on them. It's great to see how
things fall together nicely.
Regards, Peter
On 10/30/2015 08:04 PM, Mandy Chung wrote:
JEP 259:http://openjdk.java.net/jeps/259
Javadoc for the proposed StackWalker API:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
A simple way to walk the stack:
StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE);
walker.walk((s) -> s.filter(f ->
interestingClasses.contains(f.getDeclaringClass())).findFirst());
The current usage of sun.reflect.Reflection.getCallerClass(int depth) can be
replaced with this StackWalker API.
Any feedback on the proposed API is appreciated.
Mandy
P.S. webrev of the current implementation:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/webrev.00/
