Guava type inference problems

[Remi Forax]

On 11/20/2013 12:37 AM, Jonathan Ross wrote:
> Hello again,
>
> my problem below is probably also due to a well understood change to the
> type inference rules, and I am sorry if this has all been said and done
> before, but I really want to understand what's going on here.
>
> Paraphrasing some production 1.7 code using guava, I have essentially the
> following:
>
> import java.util.Collection;
> import java.util.List;
>
> abstract class TypeTest {
>
>      interface I {}
>
>      public Collection<? extends I> excludeFrom(Collection<? extends I>
> include,
>              Collection<? extends I> exclude) {
>          return copyOf(filter(include, not(in(exclude))));
>      }

My comment will not solve your problem but returning a Foo<? extends 
Bar> or a Foo<? super Bar>
is not a good idea because it forces the user code of excludeFrom to use 
wildcards too.

The wildcard mechanism was introduced to enable API writers to write 
method signature that accept to be called using subtypes/supertypes of 
parametrized types that are declared by formal parameters of the method. 
So there is no point to use wildcards in a return type.

Wildcards are tools for API writers and should not be used in code that 
use APIs.

cheers,
Rémi