Chain of Stream operations over generic types leads to Type errors

Question

The following classes and methods:

class A<T extends B> { }
class B {}

Stream<A<? extends B>> find() {
    return findAll()                        // Stream<Optional<A<? extends B>>>
            .filter(Optional::isPresent)    // Stream<Optional<A<? extends B>>>
            .map(Optional::get)             // Stream<A<capture of ? extends B>>
            .filter(a -> false);            // Stream<A<capture of ? extends B>>
}

Stream<Optional<A<? extends B>>> findAll() {
    return Stream.empty();
}

Compile fine with javac, but lead to type errors in IDEA:

The errors disappear when I either

Remove the filter(Optional::isPresent()).map(Optional::get) pair
Remove the ultimate filter call

I can't make any sense of that. Is it an IDEA bug?

Edit: Some new insights thanks to LuCio :

While my version of javac (10.0.2) does not complain, other javac versions and IDEs do, so it's not an IDEA bug
Splitting the expression in two and giving the intermediate value an explicit type helps:
```
Stream<A<? extends B>> aStream = findAll()
        .filter(Optional::isPresent)
        .map(Optional::get);
return aStream
        .filter(a -> false);
```
(note that the type IDEA infers for aStream is Stream<? extends A<? extends B>>, although it just accepts the assignment to this type)

So the question becomes: Why is the intermediate type the way it is, and why is it apparently OK to just ignore it by assigning to another type?

Have you checked that your IDEA works with the same Java version as your javac? Type inference has been improving through Java versions, your compiler may be a bit more advanced. — RealSkeptic, Oct 21 '18 at 15:32
I get the same exceptions using Eclipse Photon and Java 10. But the following works for me: `Stream> mapped = findAll().filter(Optional::isPresent).map(Optional::get); return mapped.filter(a -> false);` Though it's syntactically valid I wonder what's the purpose to filter every streamed element as `false`. This will result in an empty `Stream`. — LuCio, Oct 21 '18 at 15:51
@LuCio this was just the simplest predicate I could come up with for this example; the example is based on similar code I have that had these errors with a more elaborate Predicate in the final filter. — OhleC, Oct 21 '18 at 15:55
@ohlec I didn't change any signature. The two lines are the body of the method `Stream> find()`. Thus the signature is still the same. — LuCio, Oct 21 '18 at 15:58
@RealSkeptic as far as I can tell they should be the same (10.0.2 from openjdk-11) — OhleC, Oct 21 '18 at 17:31
@LuCio I just tried your suggestion of splitting the expression and declaring the correct type for the intermediary value in IDEA and it does in fact work there, too. — OhleC, Oct 21 '18 at 17:37
Ok, this means it works the same way in IDEA as Eclipse - no bug, no magic. — LuCio, Oct 21 '18 at 17:44
Doesn't appear to help, but as you have `A` why return `Stream>` or `Stream>>`? Just return `Stream >` and `Stream>>`. — Slaw, Feb 09 '19 at 03:16

score 2 · Accepted Answer · answered Feb 08 '19 at 15:25

2

It's because Stream.map has the following signature:

<R> Stream<R> map(Function<? super T, ? extends R> mapper);

In this case, R is A<? extends B>. Hence, the return value of the function is implicitly

? extends A<? extends B>

At which point, I believe this question is to an extent answered by

Is List<Dog> a subclass of List<Animal>? Why are Java generics not implicitly polymorphic?

This can be made to compile nicely by either changing the return type:

<T extends B> Stream<? extends A<? extends B>> find() {
    return findAll()                        // Stream<Optional<A<? extends B>>>
      .map(Optional::get)             // Stream<A<capture of ? extends B>>
      .filter(a -> false);            // Stream<A<capture of ? extends B>>
}

or explicitly casting the function to return A<? extends B>:

<T extends B> Stream<A<? extends B>> find() {
    return findAll()
      .map((Function<Optional<A<? extends B>>, A<? extends B>>) Optional::get)
      .filter(a -> false);
}

To clarify, a Stream<C>, where C extends A<B>, is not itself a Stream<A<? extends B>>.

answered Feb 08 '19 at 15:25

Ben R.

1,965
1
13
23

Right, I think the `map` signature makes it clear why there would be a covariance issue. So I guess the fact that `javac` compiles this without complaints is that it inferred the return type from the concrete function I passed in? – OhleC Feb 08 '19 at 21:00
If you're asking why your second insight worked - `Splitting the expression in two and giving the intermediate value an explicit type helps` - then yes. Assigning it to a variable with the correct signature will have the same effect as explicitly casting it as in my answer above. In one, we're explicitly casting, in the other, it's implicitly done by the compiler inferring the return type from having been assigned to that variable. – Ben R. Feb 11 '19 at 11:07
That's not what I meant — the original, unchanged code, without any casting (implicit or explicit) compiles fine with javac (10.0.2). – OhleC Feb 11 '19 at 12:58
1

Right. At this point, I don't think anyone will. I'll accept this answer, then. – OhleC Feb 11 '19 at 14:28
Thanks @OhleC, much appreciated. Shame we couldn't figure it out together! – Ben R. Feb 11 '19 at 16:32

Chain of Stream operations over generic types leads to Type errors

1 Answers1