Proposed API for JEP 259: Stack-Walking API

Andrew Dinn adinn at
Wed Nov 4 11:02:13 UTC 2015

On 04/11/15 02:59, Mandy Chung wrote:
>> On Nov 3, 2015, at 2:08 PM, David M. Lloyd <david.lloyd at>
>> wrote:
>>> 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.
> I think there is no real issue to return Thread.class either, right?

I don't understand this comment.

Several posters in this very thread have raised the issue that this
fails to disambiguate cases where there is a caller frame belonging to
Thread from those where there is no caller frame.

Have you not recognised this ambiguity or are you discounting it?


Andrew Dinn

More information about the core-libs-dev mailing list