Proposed API for JEP 259: Stack-Walking API

[Mandy Chung]

> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> 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.

That’s John’s suggestion (John always has great ideas).

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

Locals and operands is one experimental feature in mind that is not target for JDK 9.   But it would be an interesting feature for e.g. Fibers to experiment.  This will also allow JDK-specific capability to be implemented in the future. 

Another alternative is to have StackWalker subclass but making the @CS instance methods final (that may be a better way).  I can’t think of any other options to support extension.   Any suggestion is welcome.

> 
> The batchSizeMapper should probably be something better than a Function<Integer,Integer>, no?  

This batchSizeMapper function is exactly the API ’m looking for feedback.   I consider IntSupplier.  IntToLongFunction is another option.  Comment below.

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

Altering the first batch size would be useful for Log4J and Groovy use cases that filter implementation classes and finds the caller.   Altering subsequent batch size is more as a flexible option.  One can simple have the function to return the same batch size.  

I do think IntSupplier is probably a better choice that won’t restrict to supply only the initial batch size.   The last batch size parameter is solely for information.  

> Otherwise - looks nifty!  I like the StackWalker#getCallerClass() shortcut method.

Thanks
Mandy