Proposed API for JEP 259: Stack-Walking API (original) (raw)

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Oct 31 23:23:17 UTC 2015

----- Mail original -----

De: "Mandy Chung" <mandy.chung at oracle.com> À: "Remi Forax" <forax at univ-mlv.fr> Cc: core-libs-dev at openjdk.java.net Envoyé: Samedi 31 Octobre 2015 23:59:01 Objet: Re: Proposed API for JEP 259: Stack-Walking API

> On Oct 31, 2015, at 11:29 AM, Remi Forax <forax at univ-mlv.fr> wrote: > > Hi Mandy, > I've crawled the code and the documentation again. > > In the doc and in the code, a lambda with one parameter doesn't require > parenthesis around the parameter, > (s) -> s.doSomething() > should be > s -> s.doSomething(). > Oh right. (It didn’t look right to me but didn’t pay attention to it). > > In the doc of StackWalker, > in the first example, the local variable 'frame' should be named > ‘callerClass' > Fixed > > In the doc of getCallerClass(), > the first example do a skip(2) which i believe is not necessary anymore, It has to skip two frames. Use the second example, the stack looks like this: StackWalk::getCallerClass Util::getResourceBundle Foo::init : :

Ok, get it !

> also instead of Optional.orElse, orElseGet is better because it avoids to > evaluate > Thread.currentThread().getClass() if not necessary. > > So the example should be: > walk(s -> s.map(StackFrame::getDeclaringClass) > .findFirst()).orElseGet(() -> > Thread.currentThread().getClass()); > This would return Util.class instead of Foo.class > In the second example, the field walker should be declared 'final’. Sure. Fixed. > > And as i said earlier, the signature of walk() is: > T walk(Function<? super Stream<StackWalker.StackFrame>, ? extends T> > function, IntUnaryOperator batchSizeMapper) > I was pondering it and that’s why not changed in the last update. I agree with the upper bounded wildcard "? extends T” for the return type of the function. But for the function’s input argument, can you help me understand why it should take "? super Stream<StackWalker.StackFrame>”? Is it useful to have function accepting supertype of Stream rather than Stream? VM should be the only source producing this StackFrame stream.

currently this code doesn't compile, and should IMO, Function<BaseStream<StackWalker.StackFrame>, Void> fun = null; stackWalker.walk(fun);

On the other hand, I wonder if the stream argument should be Stream<? extends_ _StackFrame> that may allow future implementation change. T walk(Function<Stream<? extends StackWalker.StackFrame>, ? extends T> function, …)

A stream of ? extends StackFrame means that you can not call any methods of Stream that takes a T as parameter because the compiler can not enforce that the type is correct, so you can not call neither reduce(BinaryOperator ) nor reduce(T, BinaryOperator).

If you want to be able to send subtypes of StackFrame and know that at compile time, it's better to parameterized the StackWalker class by the type of StackFrame.

Mandy

Rémi

More information about the core-libs-dev mailing list