resolving several ivars to the same capture?
Stephan Herrmann
stephan.herrmann at berlin.de
Tue Oct 21 19:26:49 UTC 2025
Once more, I have a bunch of tests on my desk where javac and ecj disagree.
The pending fix for one case, makes ecj accept the following program, which is
rejected by javac:
//---
import java.util.function.Function;
public class Test {
public static void main(String[] args) {
C<B<?>> c = null;
m(
_ -> new A<>(c),
b -> b.intValue());
}
static <T, R> void m(Function<B<Number>, A<T>> f1, Function<T, R> f2) {}
static class A<U> {
public A(C<? extends C<U>> t) {}
}
private record B<V extends Number>(V t) implements C<V> {
}
private interface C<W> {
W t();
}
}
//---
javac reports:
Test.java:5: error: cannot infer type arguments for A<>
_ -> new A<>((C<B<?>>) null),
^
reason: cannot infer type-variable(s) U
(argument mismatch; C<B<?>> cannot be converted to C<? extends C<U>>)
where U is a type-variable:
U extends Object declared in class A
Test.java:6: error: cannot find symbol
b -> b.intValue());
^
symbol: method intValue()
location: variable b of type Object
2 errors
With my pending fix ecj would accept, with these details:
Outer inference of m() yields:
T#0 : capture#1-of ?
R#1 : java.lang.Integer
U#3 : capture#1-of ?
so m() resolves as:
void m(Function<B<Number>,A<capture#1-of ?>>, Function<capture#1-of ?,Integer>)
With target types Function<B<Number>,A<capture#1-of ?>> and
Function<capture#1-of ?,Integer> the two lambdas complete resolution just fine.
Am I missing any detail, why this inference solution is not valid?
FYI, the pending fix relates to capturing while computing super types of A<?>.
While normally we ensure uniqueness of captures per source location, when type
inference requests a capture for supertype computation we use the current
invocation as the point of reference, i.e., repeatedly capturing the same
wildcard during one invocation of type inference will share one unified capture.
Is this OK? Or what are the rules for uniqueness vs. unification in this case?
thanks,
Stephan
More information about the compiler-dev
mailing list