> On Nov 3, 2015, at 4:45 AM, Peter Levart <peter.lev...@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
