javac 8/9 inconsistency
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Feb 17 15:01:21 UTC 2015
On 17/02/15 14:39, Maurizio Cimadamore wrote:
> This is a bug - if the argument has been considered not pertinent to
> applicability - it should simply be left alone here (and then
> considered back after target-type is thrown into the mix). I will file
> a bug. Please keep such issues coming - it's probably useful for both
> parties to look at them.
Expanding a bit on this - I believe the spec is saying that the
following should result in error:
import java.util.function.*;
class Sup { }
class Sub1 extends Sup { }
class Sub2 extends Sup { }
class Test<K> {
public static void foo(Test<Sub1> test) {
Test<? extends Sup> e1 = create(Test::factory, test); //error
Test<? extends Sup> e2 = create(s -> new Test<Sub2>(), test);
//error
}
private static <A, T> T create(Function<String, T> callback, T
defaultVal) {
return null;
}
static Test<Sub2> factory(String s) {
return null;
}
}
While javac correctly compiles as it's getting two lower bounds and then
doing eager instantiation with the lub of such bound parameterizations.
Dan, do you agree? Honestly, it seems a bit gratuitous to reject such
code - is there any fundamental reason as to why we cannot go ahead and
type-check those arguments (even if they are not pertinent to
applicability) that are not stuck on any input type-variable? Could this
warrant some spec enhancement?
Maurizio
More information about the compiler-dev
mailing list