Czy to poprawna Java?

- - - edytowane w odpowiedzi na komentarze poniżej - - -

Ok, więc jest poprawna Java, ale nie powinna. Kluczem jest to, że tak naprawdę nie zależy od typu powrotu, ale od wymazanego parametru generycznego.

To nie działa na niestatycznej metodzie i jest wyraźnie zabronione na niestatycznej metodzie. Próba zrobienia tego w klasie nie powiodłaby się z powodu dodatkowych problemów, po pierwsze, typowa klasa nie jest ostateczna jak klasa {7]}.

To niekonsekwencja w skądinąd dość spójnym języku. TI zaryzykuje i powie, że to powinno być nielegalne, nawet jeśli technicznie jest dozwolone. To tak naprawdę nic nie dodaje do czytelności języka i dodaje niewiele do zdolności do rozwiązywania znaczących problemów. Jedynym znaczącym problemem, który wydaje się rozwiązać, jest to, czy jesteś na tyle zaznajomiony z językiem, aby wiedzieć, kiedy jest rdzeń Zasady wydają się być naruszane przez wewnętrzne niespójności języka w rozwiązywaniu wymazywania typów, generyków i wynikowych sygnatur metod.

Zdecydowanie należy unikać kodu, ponieważ trywialne jest rozwiązanie tego samego problemu na wiele bardziej znaczących sposobów, a jedyną korzyścią jest sprawdzenie, czy recenzent / extender zna zakurzony, brudny kącik specyfikacji języka.

- - - Original Post follows - - -

Chociaż Kompilatory mogły na to pozwolić, odpowiedź nadal brzmi nie.

Erasure zmieni zarówno listę , jak i listę w lista nierozpoznana. Oznacza to, że obie metody " f " będą miały ten sam podpis, ale różne typy zwrotów. Return type nie może być użyty do rozróżnienia metod, ponieważ nie powiedzie się, gdy powrócisz do wspólnego super-typu; jak:

Object o = f(Arrays.asList("asdf"));

Próbowałeś przechwycić zwrócone wartości do zmiennych? Być może kompilator zoptymalizował rzeczy w taki sposób, że nie nadepnął na właściwy kod błędu.

Jedno pytanie, na które nie udzielono odpowiedzi brzmi: dlaczego wywołuje błąd kompilacji tylko w Eclipse 3.6?

Oto dlaczego: jest to funkcja .

W javac 7 rozważane są dwie metody duplikaty (lub błąd kolizji nazwy) niezależnie od ich typów zwrotów.

To zachowanie jest teraz bardziej spójne z javac 1.5, który podał nazwę błędy kolizji na metodach i ignorowane ich typy zwrotów. Tylko w 1.6 był dokonana zmiana obejmowała zwrot rodzaje podczas wykrywania zduplikowanych metod.

Postanowiliśmy wprowadzić tę zmianę na wszystkich poziomach zgodności (1.5, 1.6, 1.7) w wydaniu 3.6, więc użytkownicy nie będą zaskoczeni zmianą, jeśli kompilują swój kod używając javac 7.

Cóż, jeśli dobrze rozumiem punkt trzeci z pierwszej listy z sekcji 8.4.2 spec, to mówi, że Twoje metody f () mają ten sam podpis:

Http://java.sun.com/docs/books/jls/third_edition/html/classes.html#38649

To spec naprawdę odpowiada na to pytanie, a nie obserwowane zachowanie kompilatora X lub IDE X. Wszystko, co możemy powiedzieć patrząc na Narzędzia, to jak autor narzędzia zinterpretował spec.

Jeśli zastosujemy punkt trzeci, to get:

...
    public static String f(List<String> list) {
        System.out.println("strings");
        return null;
    }

    public static Integer f(List<String> list) {
        System.out.println("numbers");
        return null;
    }
...

I podpisy się zgadzają, więc jest kolizja i Kod nie powinien się kompilować.

Jest ważny na podstawie specyfikacji.

Sygnatura metody m1 jest podpisy podpisu a metoda m2 jeżeli

• m2 posiada ten sam podpis co m1 lub

• Podpis m1 jest taki sam jak wymazanie podpisu m2.

Więc nie są to podzbiory siebie, bo wymazanie List<String> nie jest List<Integer> i vice versa.

Dwa podpisy metody m1 i m2 są override-odpowiednik iff m1 jest subsignature of m2 or m2 is a subsignature of m1.

Więc te dwa nie są równoważne (zwróć uwagę na iff ). A zasada przeciążenia jest następująca:

Jeśli dwie metody klasy (czy oba zgłoszone w tej samej klasie, lub zarówno dziedziczone przez klasę, jak i jedną deklarowane i dziedziczone) mają ta sama nazwa, ale podpisy które nie są override-odpowiednik, wtedy metoda mówi się, że nazwa jest przeciążona.

Dlatego te dwie metody są przeciążone i wszystko powinno działać.

Działa również (tym razem z sun java 1.6.0_16)

import java.util.Arrays;
import java.util.List;

class RealyCompilesAndRunsFine {

    public static String f(List<String> list) {
        return list.get(0);
    }

    public static Integer f(List<Integer> list) {
        return list.get(0);
    }

    public static void main(String[] args) {
        final String string = f(Arrays.asList("asdf"));
        final Integer integer = f(Arrays.asList(123));
        System.out.println(string);
        System.out.println(integer);
    }

}

Z tego co wiem ... plik klasy może zawierać obie metody, ponieważ deskryptor metody zawiera zarówno parametry, jak i typ zwracany. Jeśli typ zwracany byłby taki sam, to deskryptory byłyby takie same, a metody byłyby nie do odróżnienia po usunięciu typu (stąd też nie działa to z void). http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#7035

Teraz wywołanie metody z invoke_virtual wymaga metody deskryptor, więc możesz w rzeczywistości powiedzieć, którą z metod chcesz wywołać, więc wydaje się, że wszystkie te Kompilatory, które nadal mają Informacje ogólne, po prostu umieścić deskryptor dla metody, która pasuje do ogólnego typu parametru, więc wtedy jest zakodowany na twardo w bajtkodzie, która metoda do wywołania (co odróżnia się ich deskryptorami, lub dokładniej przez typ zwracania w tych deskryptorach), nawet jeśli parametr jest teraz listą, bez informacji ogólnych.

While I find ta praktyka jest trochę wątpliwa, muszę powiedzieć, że uważam to za fajne, że możesz to zrobić i myślę, że leki generyczne powinny być zaprojektowane tak, aby mogły działać w ten sposób w pierwszej kolejności (tak, Wiem, że spowodowałoby to problemy z kompatybilnością wsteczną).

Wnioskowanie typu Java (co się dzieje, gdy wywołujesz statyczne, ogólne metody, takie jak Array.asList) jest skomplikowana i nie jest dobrze określona w JLS. Ten artykuł z 2008 roku ma bardzo ciekawy opis niektórych problemów i jak można je naprawić:

Wnioskowanie typu Java jest zepsute: jak możemy to naprawić?

Eclipse może wygenerować kod bajtowy z tego:

public class Bla {
private static BigDecimal abc(List<BigDecimal> l) {
    return l.iterator().next().multiply(new BigDecimal(123));
}

private static String abc(List<String> l) {
    return l.iterator().next().length() + "";
}

public static void main(String[] args) {
    System.out.println(abc(Arrays.asList("asdf")));
    System.out.println(abc(Arrays.<BigDecimal>asList(new BigDecimal(123))));
}
}

Wyjście:

4

15129

Wygląda na to, że kompilator wybiera najbardziej specyficzną metodę opartą na generykach.

import java.util.Arrays;
import java.util.List;

class TestWillThatCompile {

public static Object f(List<?> list) {
    System.out.println("strings");
    return null;
}

public static Integer f(List<Integer> list) {
    System.out.println("numbers");
    return null;
}

public static void main(String[] args) {
    f(Arrays.asList("asdf"));
    f(Arrays.asList(123));
}

}

Wyjście:

strings
numbers