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