9
Tak, mam następujący kod:Wnioskowany problem typu Java 1.8.0_65
public class Tester {
public static void doAssert(Object foo, Object bar) {
}
public static void doAssert(Object[] foo, Object[] bar) {
}
public static <T> T getValue(String name, Function<String, T> covert) {
return null;
}
public static void main (String[] args) {
doAssert(getValue("", Double::valueOf), null);
}
}
Gdybym to skompilować z javac v1.8.0_05, to działa prawidłowo. Pod 1.8.0_65, pojawia się następujący błąd (jak donosi z -Xdiags:verbose):
Tester.java:32: error: method doAssert in class Tester cannot be applied to given types;
doAssert(null, getValue("", Double::valueOf));
^
required: Object[],Object[]
found: <null>,Double
reason: argument mismatch; inferred type does not conform to upper bound(s)
inferred: Double
upper bound(s): Object[],Object
1 error
ten znika, jeśli jawnie rzutować null argument Double lub jeśli usunąć Object[] przeciążenie doAssert.
A więc ... czy jest to regresja w wersji 1.8.0_65 lub jednej z innych interweniujących wersji, czy też 1.8.0_05 był nadmiernie permisywny? I dlaczego javac nie może zrozumieć, co ma robić?
(ponownie: głosowanie przybliżone - dla mnie nie jest oczywiste, jak drugi Q & A jest duplikatem, a powiązane pytania nie wydają się zajmować problemem przeciążenia metody, który jest wymagany do odtworzenia tego problemu.)
Powtórzyłem ten błąd z 1.8.0_60 (uwaga: Eclipse Mars 4.5.1 kompiluje to dobrze). IMO to powinno się skompilować dobrze. – Tunaki
Możliwy duplikat [Czy istnieje regresja wnioskowania typu w aktualizacji JDK 8 20?] (Http://stackoverflow.com/questions/25490581/is-there-a-type-inference-regression-in-jdk-8-update -20) –
dobrze - czy powinien się skompilować? rozdzielczość przeciążania zależy od typów argumentów; jednak tutaj typy argumentów muszą być wywnioskowane z typów parametrów, co wymaga wcześniejszego rozwiązania problemu przeciążenia ... nie jest to banalny problem. Powodzenia w czytaniu specyfikacji - pisarze kompilacji zrobili :) – ZhongYu