Proposed API for JEP 259: Stack-Walking API

[Remi Forax]

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)

In StackWalker.Option,
i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ?

In StackWalker.StackTrace,
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
> 

regards,
Rémi