Proposed API for JEP 259: Stack-Walking API

[Paul Sandoz]

Hi Mandy,

My recommendation is to go with with PECS whenever possible, even if some aspects are redundant.

Paul.

> On 5 Nov 2015, at 22:48, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Nov 4, 2015, at 5:00 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> 
>>> Good point. Damn, i don’t like wildcards :-)
>>> 
>>> The following works fine:
>>> 
>>> static <T> Function<Stream<T>, Long> counter() {
>>>     return Stream::count;
>>> }
>>> 
>>> But there could also cases where one is stuck using a wildcard:
>>> 
>>> Function<Stream<?>, Long> f = Stream::count;
>> 
>> 
>> Wildcards are not that complex, but because they are use-side annotations, it's really easy to forget them, and IDEs do not help here :(
>> 
>> I really hope that the JEP about declaration site variance [1] will be implemented at the beginning of jdk 10, it will remove the need of wildcards for functional interfaces.
>> 
> 
> Remi, Paul,
> 
> The current StackWalker::walk method:
>    <T> T walk(Function<Stream<StackFrame>, T> function)
> 
> This would mean that the StackWalker API is intended to work with a function taking Stream<StackFrame> but not Stream<?>.
> 
> Changing to
>    <T> T walk(Function<? super Stream<StackFrame>, ? extends T> function)
> 
> will allow use of some existing functions taking Stream<?>.  I don’t object changing it to use wildcard.
> 
> However, the StackWalker API is specific for reading StackFrame and I would expect it’s reasonable if it doesn’t work with a function taking Stream<?> as the useful functions such as Stream::count, Stream::collect(Collectors.toList(…)) can be used.
> 
> Just want to double confirm the advice which way to go.
> 
> Mandy