Proposed API for JEP 259: Stack-Walking API

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.CLASS_REFERENCE);
>     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.

-- 
- DML



More information about the core-libs-dev mailing list