Краткий ответ

Явно указанный аргумент типа заранее фиксирует параметр обобщённого метода и заставляет компилятор проверить все аргументы и возвращаемый результат именно относительно этого типа. При автоматическом выводе компилятор подбирает подходящий тип по контексту вызова, аргументам и ограничениям метода.

Явное указание не является приведением типа: оно не отключает проверку совместимости и не меняет стирание типов во время выполнения.

Исторический контекст

Generics появились в Java для статической типобезопасности коллекций и обобщённых алгоритмов без постоянных приведений типов. При этом реализация через стирание типов сохранила совместимость с уже существующим байткодом и библиотеками.

Автоматический вывод типа уменьшает шаблонный код, но иногда выбранный компилятором тип не совпадает с типом, который требуется выразить в контракте вызова. Для таких случаев Java позволяет явно задать аргумент типа перед именем метода.

Постановка проблемы

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

Замена явного аргумента типа на приведение результата опаснее: приведение лишь меняет ожидаемый статический тип выражения и может скрыть ошибку, которая проявится во время выполнения. Явный аргумент типа, напротив, проверяется компилятором вместе с остальными ограничениями.

Подробное решение

Сначала компилятор рассматривает явно заданный тип как значение параметра метода T. Затем он проверяет, что каждый фактический аргумент совместим с параметром метода после подстановки T, а сам T удовлетворяет своим верхним границам.

class Demo {
    static <T> T identity(T value) {
        return value;
    }

    public static void main(String[] args) {
        Integer exact = identity(1);
        Number wider = Demo.<Number>identity(1);
        // String invalid = Demo.<String>identity(1);
    }
}

В первом вызове тип T выводится как Integer. Во втором он явно зафиксирован как Number, поэтому результат имеет статический тип Number; значение Integer передаётся туда благодаря обычной совместимости подтипов. Третий вызов не компилируется: Integer нельзя передать туда, где после подстановки ожидается String.

Явный аргумент типа может быть только допустимым типом с точки зрения границ параметра. Если метод объявлен с верхней границей T extends Number, указание String будет отвергнуто ещё на этапе компиляции.

Во время выполнения отдельной специализации метода для каждого T обычно не появляется: после стирания типов параметр T заменяется своей границей либо Object, а необходимые проверки и приведения добавляются компилятором. Поэтому явное указание типа влияет на статическую проверку и тип результата в исходном коде, но не создаёт новый runtime-тип метода.

Ситуация из практики

В библиотечном API есть обобщённый метод преобразования, который возвращает T. Клиенту нужно объявить результат как Number, чтобы не связывать публичный контракт с текущей конкретной реализацией, например с Integer.

Вариант с автоматическим выводом удобен и обычно предпочтителен: код короче, а компилятор выбирает тип из контекста. Однако выбранный тип может оказаться слишком конкретным для читаемого контракта или измениться после изменения аргументов метода.

Вариант с приведением результата короче явной записи, но хуже документирует намерение и может скрыть ошибочную совместимость. Выбранное решение — явный аргумент типа Number: он одновременно фиксирует контракт, проверяется компилятором и не добавляет риск неконтролируемого приведения.

Что кандидаты часто упускают

Можно ли явным аргументом типа обойти верхнюю границу параметра?

Нет. Если параметр объявлен как T extends Number, явно указать String нельзя. Явная запись не является обходом системы типов: компилятор проверяет, что выбранный тип является подтипом каждой требуемой границы.
Меняет ли явное указание типа поведение метода во время выполнения?

Обычно нет. При стирании типов разные вызовы обобщённого метода используют одну реализацию, а параметр типа исчезает из сигнатуры байткода или заменяется своей границей. Меняются статические типы выражений и результаты проверок компилятора, но не появляется отдельная специализация метода для Integer, Number и других аргументов.
Может ли явный аргумент типа сделать несовместимые аргументы допустимыми?

Нет. Он, наоборот, фиксирует дополнительные ограничения. Например, если один параметр метода после подстановки требует List<Number>, передача List<Integer> всё равно будет отвергнута из-за инвариантности параметризации. Явное указание типа не заменяет wildcard, приведение или другой корректный дизайн сигнатуры.