On 11/03/2015 03:33 PM, Mandy Chung wrote:
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.
I'll say it: I don't think the world will fall apart if it just returns
null when there's no caller. Some might even consider that to be intuitive.
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.
I think Class objects are safe even without the weird new isolation
rules, but that's a discussion for another mailing list :)
--
- DML
