> On Oct 30, 2015, at 12:59 PM, David M. Lloyd <david.ll...@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

Reply via email to