-
Enhancement
-
Resolution: Unresolved
-
P4
-
8, 9
This test case:
abstract class Test {
interface One {
void f();
}
abstract <T> T verify(T t);
abstract <T extends One> T create();
void m() {
verify(create()).f();
}
}
used to compile with javac7's greedy approach, it's not accepted by javac8. While inferring the type of the call:
verify(create())
The following constraints set is generated:
{T1 <: Object, T2 <: T1, T2 <: One, T2 <: Object}
what is happening later in javac is that T2 is instantiated to One, but this instantiation is not reflected on T1's lower bound and T1 is instantiated to Object and thus the code doesn't compile. The reason for this is that there is no predictable way to select which variable T1 or T2 to instantiate first so the instantiation of one variable don't affect the other variable. It would be interesting to determine if a given heuristic can find a compatible solution in a predictable way.
abstract class Test {
interface One {
void f();
}
abstract <T> T verify(T t);
abstract <T extends One> T create();
void m() {
verify(create()).f();
}
}
used to compile with javac7's greedy approach, it's not accepted by javac8. While inferring the type of the call:
verify(create())
The following constraints set is generated:
{T1 <: Object, T2 <: T1, T2 <: One, T2 <: Object}
what is happening later in javac is that T2 is instantiated to One, but this instantiation is not reflected on T1's lower bound and T1 is instantiated to Object and thus the code doesn't compile. The reason for this is that there is no predictable way to select which variable T1 or T2 to instantiate first so the instantiation of one variable don't affect the other variable. It would be interesting to determine if a given heuristic can find a compatible solution in a predictable way.