Ogólna granica górnego typu zwracanego typu - interfejs a klasa - zaskakująco poprawny kod

To jest prawdziwy przykład z interfejsu API biblioteki innej firmy, ale uproszczony.

Skompilowano za pomocą Oracle JDK 8u72

Rozważ te dwie metody:

<X extends CharSequence> X getCharSequence() {
    return (X) "hello";
}

<X extends String> X getString() {
    return (X) "hello";
}

Obaj zgłaszają ostrzeżenie o „niesprawdzonej obsadzie” - rozumiem dlaczego. Zdumiewa mnie to, dlaczego mogę zadzwonić

Integer x = getCharSequence();

i się kompiluje? Kompilator powinien wiedzieć, że Integernie implementuje CharSequence. Wezwanie do

Integer y = getString();

daje błąd (zgodnie z oczekiwaniami)

incompatible types: inference variable X has incompatible upper bounds java.lang.Integer,java.lang.String

Czy ktoś może wyjaśnić, dlaczego takie zachowanie miałoby zostać uznane za ważne? Jak by to było przydatne?

Klient nie wie, że to wywołanie jest niebezpieczne - kod klienta kompiluje się bez ostrzeżenia. Dlaczego kompilacja nie ostrzegłaby o tym / nie spowodowała błędu?

Czym różni się od tego przykładu:

<X extends CharSequence> void doCharSequence(List<X> l) {
}

List<CharSequence> chsL = new ArrayList<>();
doCharSequence(chsL); // compiles

List<Integer> intL = new ArrayList<>();
doCharSequence(intL); // error

Próba zaliczenia List<Integer>powoduje błąd, zgodnie z oczekiwaniami:

method doCharSequence in class generic.GenericTest cannot be applied to given types;
  required: java.util.List<X>
  found: java.util.List<java.lang.Integer>
  reason: inference variable X has incompatible bounds
    equality constraints: java.lang.Integer
    upper bounds: java.lang.CharSequence

Jeśli jest to zgłaszane jako błąd, dlaczego Integer x = getCharSequence();tak nie jest?

CharSequencejest interface. Dlatego nawet jeśli SomeClassnie implementuje CharSequence, byłoby doskonale możliwe utworzenie klasy

class SubClass extends SomeClass implements CharSequence

Dlatego możesz pisać

SomeClass c = getCharSequence();

ponieważ typ wywnioskowany Xjest typem skrzyżowania SomeClass & CharSequence.

Jest to trochę dziwne w przypadku, Integergdy Integerjest ostateczne, ale finalnie odgrywa żadnej roli w tych zasadach. Na przykład możesz pisać

<T extends Integer & CharSequence>

Z drugiej strony, Stringnie jest interface, więc niemożliwe byłoby rozszerzenie w SomeClasscelu uzyskania podtypu String, ponieważ java nie obsługuje wielokrotnego dziedziczenia dla klas.

W tym Listprzykładzie należy pamiętać, że typy ogólne nie są ani kowariantne, ani kontrawariantne. Oznacza to, że jeśli Xjest podtypem Y, List<X>nie jest ani podtypem, ani nadtypem List<Y>. Ponieważ Integernie implementuje CharSequence, nie możesz używać List<Integer>w swojej doCharSequencemetodzie.

Możesz jednak zmusić to do kompilacji

<T extends Integer & CharSequence> void foo(List<T> list) {
    doCharSequence(list);
}  

Jeśli masz metodę, która zwraca następującą wartośćList<T> :

static <T extends CharSequence> List<T> foo() 

możesz to zrobić

List<? extends Integer> list = foo();

Dzieje się tak, ponieważ typem wywnioskowanym jest Integer & CharSequencei jest to podtyp Integer.

Typy przecięć występują niejawnie, gdy określisz wiele granic (np <T extends SomeClass & CharSequence>.).

Więcej informacji można znaleźć w części JLS, w której wyjaśniono, jak działają ograniczenia typów. Możesz dołączyć wiele interfejsów, np

<T extends String & CharSequence & List & Comparator>

ale tylko pierwsza granica może nie być interfejsem.

Typ, który jest wywnioskowany przez kompilator przed przypisaniem, Xto Integer & CharSequence. Ten typ wydaje się dziwny, ponieważ Integerjest ostateczny, ale jest to całkowicie poprawny typ w Javie. Następnie jest rzucany na Integer, co jest całkowicie OK.

Istnieje dokładnie jedna możliwa wartość dla Integer & CharSequencetypu: null. Z następującą implementacją:

<X extends CharSequence> X getCharSequence() {
    return null;
}

Następujące zadanie będzie działać:

Integer x = getCharSequence();

Z powodu tej możliwej wartości nie ma powodu, dla którego przypisanie powinno być błędne, nawet jeśli jest oczywiście bezużyteczne. Przydałoby się ostrzeżenie.

Prawdziwym problemem jest interfejs API, a nie witryna wywołań

W rzeczywistości niedawno pisałem na blogu o tym wzorcu anty projektowania API . Nie należy (prawie) nigdy projektować ogólnej metody zwracania dowolnych typów, ponieważ (prawie) nigdy nie można zagwarantować, że wywnioskowany typ zostanie dostarczony. Wyjątkiem są metody takie jak Collections.emptyList(), w przypadku których pustka listy (i wymazanie typu ogólnego) jest powodem, dla którego wszelkie wnioskowanie for <T>zadziała:

public static final <T> List<T> emptyList() {
    return (List<T>) EMPTY_LIST;
}