Proposed API for JEP 259: Stack-Walking API
forax at univ-mlv.fr
Fri Oct 30 20:26:50 UTC 2015
Hi Mandy, hi David, hi all,
the API look gorgeous :)
There are some missing wildcards in walk,
<T> T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> function, IntUnaryOperator batchSizeMapper)
i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ?
i think that asStackTraceElement() should be called toStackTraceElement(), like Path.toFile, it's a convenient method to convert a StackFrame instance to the legacy class StackTraceElement.
The documentation of getDeclaringClass() is not clear that it throws UOE if the walker is not configured with CLASS_REFERENCE.
----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at redhat.com>
> À: core-libs-dev at openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 20:59:26
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
> 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.
store the stream in an instance or a static variable ?
> 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.
I agree with David, having another implementation is unlikely.
> 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?
IntToIntFunction => IntUnaryOperator.
> Otherwise - looks nifty! I like the StackWalker#getCallerClass()
> shortcut method.
> - DML
More information about the core-libs-dev