filtering a stream changes its wildcard bounds?

Question

the below method compiles without problems:

static Stream<Optional<? extends Number>> getNumbers(Stream<Number> numbers) {
    return numbers.map(Optional::of);
}

yet if I add a simple filtering to it like this:

static Stream<Optional<? extends Number>> getNumbers2(Stream<Number> numbers) {
    return numbers.map(Optional::of).filter(number -> true);
}

it generates the following error:

incompatible types:
java.util.stream.Stream<java.util.Optional<java.lang.Number>> cannot be converted to
java.util.stream.Stream<java.util.Optional<? extends java.lang.Number>>

tested on openJdk-11 and openJdk-17.

I'd expect them both to do the same (either both compile ok or both generate the same compilation error), so I'm really puzzled by this: what is the general rule here that explains why the 1st method compiles ok yet the 2nd does not? Thanks!

Leadwort

Stream<? extends Optional<? extends Number>> seems to do the trick, but I wonder why – Fluviatile

Answer 1

Compatibility with the return type Stream<Optional<? extends Number>> in the first case is not obtained by virtue of numbers.map(Optional::of) returning a Stream<Optional<? extends Number>> on its own; it's the compiler inferring the return type of numbers.map(...) due to it being a generic method:

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

while Stream.filter() is not:

Stream<T> filter(Predicate<? super T> predicate);

Therefore, in the first case the compiler can take into account the return statement's context (getNumbers's type) when inferring type of numbers.map(...).
Compiler cannot do the same for numbers.map(...) in the second case, as there are subsequent chained calls, that may further change the type, so it would be very hard to guess what the right inferring should be at this stage. As a result, the most specific possible type is assumed for numbers.map(...) (Stream<Optional<Number>>) and further carried on by filter(...).

As a different example to illustrate that, please figure out why both of these compile (List.of() is the same code, after all):

static List<String> stringList() {
    return List.of();
}
static List<Integer> intList() {
    return List.of();
}

Now, why does this fail:

static List<String> stringList() {
    return List.of().subList(0, 0);
}

That's because List.subList(...) does not infer the returned list's E type in context (i.e., the method is not generic), it carries the List instance's E type, which, with List.of() in that case gets defaulted to Object (yes, when you have return List.of();, return type inference kicks in, forcing the compiler to figure out that the intent is to make E match String, the type argument in the method's return type). Please note that this gets more complex than that, there are corners where inference doesn't work as wished/expected.

---

Short answer: return numbers.map(Optional::of) takes advantage of type inference as map() is generic, and filter() does not, expecting the E of Stream<E> to be carried. And with numbers.map(Optional::of), E is Optional<Number>, not Optional<? extends Number>, and filter carries that.

Yearwood

I still don't understand what prevents the compiler in the second case to do a type analysis of numbers.map(...) part first, take advantage of type inference as you explained and then apply filter(...) to it... – Leadwort

ahh, I think I get it: in case of partial type analysis, it lacks the context what to infer it to (there may be other mappings later that change type back and forth, so it would be very hard for compiler to guess what the right inference should be at this stage). – Leadwort

@Leadwort Spot on. The compiler doesn't carry inferred types when there are chained methods afterwards. Well, it pretty much doesn't do type inference in that case. – Yearwood