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.ll...@redhat.com> > À: core-libs-dev@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
