Proposed API for JEP 259: Stack-Walking API (original) (raw)

David M. Lloyd david.lloyd at redhat.com
Fri Oct 30 19:59:26 UTC 2015

On 10/30/2015 02: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.CLASSREFERENCE); 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/

Clever/interesting way to prevent the stream from being used outside of the stack frame it is active in. I was trying to think of a way it could be subverted but I haven't come up with one yet.

Since this is very likely to be a one-implementation API, is there a reason to have a separate WalkerOption interface and Option enum? Seems like you could just skip the interface.

The batchSizeMapper should probably be something better than a Function<Integer,Integer>, no? All that boxing seems unnecessary... the next best candidate I can see though is IntToLongFunction. I wonder why we didn't do an IntToIntFunction in JSR 335. Or maybe the stream itself should be somehow made aware of the optimum batch size. What's the use case for changing the batch size as you iterate? Is the traversal that expensive?

Otherwise - looks nifty! I like the StackWalker#getCallerClass() shortcut method.

--

More information about the core-libs-dev mailing list