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

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

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

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

Такой подход позволил внедрить generics без отдельной версии JVM, но сделал особенно важным различие между обобщённым методом и методом обобщённого класса.

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

Разработчик может ожидать, что метод, принимающий String, переопределит метод, принимающий произвольный тип. На самом деле базовый метод по-прежнему принимает любой объект, а метод наследника — только строку.

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

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

У обобщённого метода параметр типа является частью объявления самого метода. Например, метод вида <T> T преобразовать(T значение) обещает работать с любым T. Метод String преобразовать(String значение) предлагает только один частный случай и не может заменить общий контракт.

Такой метод может быть допустимой перегрузкой, но не переопределением. Если вызов выполняется через ссылку базового типа, специализированный метод вообще не входит в набор доступных методов; если через тип наследника — выбор зависит от статического типа аргумента.

Иная ситуация возникает у обобщённого класса:

class Box<T> {
    T get(T value) { return value; }
}

class StringBox extends Box<String> {
    @Override
    String get(String value) { return value.trim(); }
}

Здесь после подстановки T в String сигнатура базового метода совпадает с методом наследника, поэтому это корректное переопределение. Для сохранения полиморфизма компилятор может сгенерировать синтетический bridge-метод, который принимает более общий тип и делегирует специализированной реализации.

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

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

В базовом сервисе объявлен обобщённый метод обработки любого объекта. Разработчик добавляет в наследник метод обработки только строк и ожидает, что вызов сервиса через базовую ссылку начнёт обрабатывать строки специальным образом.

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

Надёжное решение — параметризовать сам базовый класс или интерфейс и создать специализированный наследник. Тогда контракт после подстановки типов совпадает, компилятор проверяет @Override, а полиморфный вызов сохраняется. Это уменьшает риск незаметного обхода специализированной логики.

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

Что произойдёт при наличии метода с конкретным параметром в наследнике?

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

Почему аннотация @Override полезна именно в этой ситуации?

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

Зачем нужен bridge-метод при специализации обобщённого класса?

После стирания типов базовый метод может принимать Object, тогда как реализация наследника — String. Bridge-метод сохраняет совместимую JVM-сигнатуру базового контракта и перенаправляет вызов в метод со специализированным типом. При неправильном фактическом типе аргумента возможна проверка и исключение ClassCastException внутри такого моста.