Верхня межа загального типу повернення - інтерфейс проти класу - напрочуд вірний код

Це приклад із реального світу з API сторонньої бібліотеки, але спрощений.

Укладено з Oracle JDK 8u72

Розглянемо ці два методи:

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

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

Обидва повідомляють про попередження "без перевірки" - я розумію, чому. Що мене бентежить, це те, чому я можу дзвонити

Integer x = getCharSequence();

і вона компілює? Компілятор повинен знати, що Integerне реалізується CharSequence. Заклик до

Integer y = getString();

видає помилку (як очікувалося)

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

Чи може хтось пояснити, чому б така поведінка вважалася дійсною? Як це було б корисно?

Клієнт не знає, що цей дзвінок небезпечний - код клієнта складається без попередження. Чому компілятор не попередив би про це / не видав помилку?

Також, чим він відрізняється від цього прикладу:

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

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

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

Спроба пройти List<Integer>подає помилку, як очікувалося:

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

Якщо це повідомляється як помилка, чому Integer x = getCharSequence();ні?

CharSequenceє interface. Тому навіть якщо SomeClassце не реалізується, CharSequenceбуло б цілком можливо створити клас

class SubClass extends SomeClass implements CharSequence

Тому ви можете писати

SomeClass c = getCharSequence();

тому що виведений тип X- це тип перетину SomeClass & CharSequence.

Це трохи дивно у тому випадку, Integerоскільки Integerє остаточним, але finalне грає жодної ролі в цих правилах. Наприклад, ви можете написати

<T extends Integer & CharSequence>

З іншого боку, Stringце не є interface, тому неможливо було б розширити SomeClassотримання підтипу String, тому що java не підтримує багатонаступне успадкування для класів.

На Listприкладі потрібно пам’ятати, що дженерики не є ні коваріантними, ні противаріантними. Це означає, що якщо Xє підтипом Y, List<X>не є ні підтипом, ні супертипом List<Y>. Оскільки Integerне реалізується CharSequence, ви не можете використовувати List<Integer>у своєму doCharSequenceметоді.

Однак ви можете отримати це для компіляції

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

Якщо у вас є метод , який повертаєList<T> як це:

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

Ви можете зробити

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

Знову ж таки, це тому, що певний тип є, Integer & CharSequenceі це підтип Integer.

Типи перетину виникають неявно, коли ви вказуєте декілька меж (наприклад, <T extends SomeClass & CharSequence>).

Для отримання додаткової інформації, ось частина JLS, де пояснюється, як працюють межі типу. Ви можете включати кілька інтерфейсів, наприклад

<T extends String & CharSequence & List & Comparator>

але лише перша межа може бути неінтерфейсом.

Тип, на який походить ваш компілятор перед призначенням, Xє Integer & CharSequence. Цей тип виглядає дивним, оскільки Integerє остаточним, але це абсолютно дійсний тип на Java. Тоді його передають Integer, що цілком нормально.

Існує рівно один з можливих значень для Integer & CharSequenceтипу: null. З наступною реалізацією:

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

Наступне завдання спрацює:

Integer x = getCharSequence();

Через таку можливу цінність немає жодної причини, чому призначення має бути неправильним, навіть якщо воно, очевидно, марне. Попередження було б корисним.

Справжня проблема - API, а не сайт виклику

Насправді, я нещодавно веду журнал про цю антидіапазон дизайну API . Ви не повинні (майже) ніколи не розробляти загальний метод повернення довільних типів, оскільки ви можете (майже) ніколи не гарантувати, що отриманий тип буде доставлений. Виняток становлять такі методи, як Collections.emptyList(), якщо порожнеча списку (і стирання загального типу) є причиною того, що будь-який висновок <T>буде працювати:

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