Proposed API for JEP 259: Stack-Walking API

[Mandy Chung]

> On Nov 3, 2015, at 4:45 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 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?

That should be Thread.class.

> 
> 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?
> 

I considered Optional<Class<?>>. I believe it is rare to have a JNI attached thread calling StackWalker::getCallerClass from native.  Most common cases will find a caller class.   Returning an Optional will force most common uses to handle the case if it’s absent.  It’s a tradeoff that I think it’s better to return Thread.class for the JNI attached thread calling getCallerClass in native which would rarely happen.


> 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.

Yup.  I’m really looking forward to the strong encapsulation that strengthens the security.
Mandy