Proposed API for JEP 259: Stack-Walking API

[Mandy Chung]

> On Oct 30, 2015, at 1:26 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Mandy, hi David, hi all,
> the API look gorgeous :)
> 

Thank you.

> 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 ?
> 

That’s a good alternative.  

> 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. 

StackFrame has all the information StackTraceElement has.  It doesn’t seem that this method is necessary.   I’m tempted to remove this default method.   Any thought?

> The documentation of getDeclaringClass() is not clear that it throws UOE if the walker is not configured with CLASS_REFERENCE.
> 

I’ll fix that.

> ----- Mail original -----
>> 
>> 
>> 
>> 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 ?
> 

I have a test for all these cases.

>> 
>> 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.

That’s for an experimental capability (see my other reply).

> 
>> 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.
> 

Thanks.

Mandy