Подстановочный знак с нижней границей не проверяется на соответствие параметру типа с верхней границей

Такое поведение компилятора обсуждалось в этой ошибке Eclipse. Первоначально компилятор Eclipse сделал ошибку для выражения в вашем примере, а javac - нет. Хотя я еще не искал JLS напрямую, похоже, что консенсус заключается в том, что в спецификации нет ничего, требующего проверки подстановочных знаков с нижней границей на соответствие границам параметров типа. В этой ситуации в конечном итоге вызывающая сторона должна назначить тип, который удовлетворяет ограничениям (как предположил Стефан Херрманн в этом посте).

Это удивительно бессмысленный фрагмент кода.

Все, что он говорит, это то, что класс A принимает общий тип K, который является Number, и есть метод useMe, который возвращает A<T> с некоторыми бессмысленными дополнительными ограничениями на T (кроме Number, очевидно).

Вот реализация, показывающая, как мало говорит сахар:

abstract class A<K extends Number> {
    public abstract <M> A<? super M> useMe(A<? super M> k);
}

class B extends A<Number> {

    @Override
    public <M> A<? super M> useMe(A<? super M> k) {
        // Not much more you can do here but this.
        return k;
    }

}

Материал ? super M просто бессмысленная абракадабра - все, что компилятор может извлечь из него, это то, что и переданный ему параметр, и возвращаемый результат должны быть суперклассом определенного безымянного класса.

Обобщения предназначены для облегчения обнаружения ошибок кодирования во время компиляции. Использование такой чепухи просто вводит в заблуждение.

Добавление <M extends Number> к первому примеру не добавляет ничего важного для компилятора. Помните, что вы говорите «тип, который является супертипом M», если мы говорим «M является подтипом Number» и «тип является супертипом M», мы на самом деле не говорим, является ли тип подтипом M. Количество.

Для лучшего примера пусть M будет Integer, а переменная будет типа A<Object>. Хотя очевидно, что это не сработает, оно правильно удовлетворяет всем требованиям функции.

Поскольку не существует способа исправить определение функции, он просто пропускает его и предполагает, что сайт вызова обнаружит проблему.

В вашем вопросе две части:

Часть 1: Что такое <M>?

Наличие универсального параметра в методе делает его «типизированным методом», что означает, что метод имеет универсальный тип, который определяется вызывающей стороной, обычно путем логического вывода. Он может быть ограничен. Если у класса тоже есть тип, а метод является методом экземпляра, эти два типа не связаны.

Часть 2:

Общие типы должны соответствовать точно. Причина сводится к тому, что если B является подтипом A, то SomeClass<T extends B> не является подтипом SomeClass<T extends A>, точнее, SomeClass<A> не является подтипом SomeClass<? super A>.