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

Java стирает параметры обобщённых типов при компиляции, поэтому методы, различающиеся только параметрами вроде List<String> и List<Integer>, после стирания получают одинаковую сигнатуру List. Такая перегрузка привела бы к конфликту методов, поэтому компилятор отклоняет её ещё до выполнения программы.

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

Обобщения появились в Java 5, но язык сохранил совместимость с существующим кодом и библиотеками, не требовавшими знания о generic-типах. Для этого используется стирание типов: большая часть информации о параметрах обобщённых типов доступна компилятору, но не сохраняется в обычной сигнатуре метода для диспетчеризации во время выполнения.

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

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

Представим класс, которому нужно по-разному обрабатывать список строк и список чисел. Интуитивно можно попытаться объявить два метода с одинаковым именем и параметрами List<String> и List<Integer>.

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

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

При компиляции Java проверяет generic-типы и может использовать их для проверки совместимости, приведения и выбора некоторых операций. Затем параметризованные типы стираются: List<String> и List<Integer> становятся List, а параметр типа T обычно заменяется его верхней границей, например Object.

Поэтому следующие объявления считаются конфликтующими:

import java.util.List;

class Processor {
    void process(List<String> values) {}
    void process(List<Integer> values) {}
}

После стирания оба метода выглядели бы как process(List). Java не может различить их по возвращаемому типу: возвращаемый тип не входит в сигнатуру метода для перегрузки. Также нельзя решить конфликт проверкой фактического типа элементов, потому что из-за стирания List<String> и List<Integer> в рантайме обычно представлены одним классом.

Допустимая альтернатива — различать методы параметрами, сохраняющими разную сигнатуру после стирания, либо использовать один generic-метод с общей логикой. Но generic-метод не всегда заменяет две реализации: если поведение действительно зависит от типа элементов во время выполнения, тип нужно передать явно, использовать отдельный параметр или применить другой дизайн API.

Важно отличать этот случай от перегрузки по обычным типам: process(List<String>) и process(Set<String>) допустимы, потому что после стирания параметры остаются List и Set. Ограничения generic-типа также могут вызвать конфликт: параметры T и U с одинаковыми границами стираются в один и тот же тип.

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

В библиотеке обработки данных потребовались отдельные операции для списков строк и чисел. Первый вариант пытался создать две перегрузки с параметрами List<String> и List<Integer>, но проект не компилировался из-за одинаковой стёртой сигнатуры.

Вариант с двумя разными именами методов решал проблему и был прост для вызова, но раздувал API. Вариант с одним методом, принимающим List<?>, устранял дублирование, однако требовал проверки элементов и не позволял безопасно выразить все различия на этапе компиляции.

Выбрали один generic-метод для одинаковой алгоритмической логики, а для действительно разного поведения добавили явный объект стратегии. Это сохранило типобезопасность, избежало конфликта стирания и сделало зависимость от типа поведения явной. В результате API не зависел от невозможной перегрузки по generic-параметрам.

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

1. Можно ли перегрузить методы, если они отличаются только возвращаемым типом?

Нет. Возвращаемый тип не участвует в сигнатуре метода при выборе перегрузки, поэтому два метода с одинаковым именем и параметрами, но разными результатами конфликтуют. Иначе вызов без использования результата был бы неоднозначным.

2. Всегда ли generic-информация полностью исчезает во время выполнения?

Нет. Параметры generic-типов обычно стираются из типов объектов и сигнатур методов, но информация о параметризации может сохраняться в метаданных класса или метода и читаться через reflection, например для анализа объявленного поля с generic-типом. Это не означает, что JVM может использовать List<String> и List<Integer> как разные runtime-типы объектов.

3. Как Java сохраняет полиморфизм generic-метода после стирания ограниченного типа?

Компилятор может создать синтетический мостовой метод. Например, если generic-метод после стирания должен принимать Object, а переопределённая реализация фактически принимает более конкретный тип, мост адаптирует вызов и выполняет нужное приведение. Это поддерживает корректное переопределение, но не делает разные параметризованные типы различимыми для перегрузки.