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

Причина кроется в механизме стирания типов (Type Erasure):

🟢 Junior Level

Нет, нельзя. Попытка объявить такие методы приведёт к ошибке компиляции:

name clash: methods have the same erasure (конфликт имён: методы имеют одинаковое стирание типов).

public class Printer {
    // ❌ Ошибка компиляции: name clash
    public void print(List<String> list) {
        System.out.println("Strings: " + list);
    }

    // ❌ Ошибка компиляции: name clash
    public void print(List<Integer> list) {
        System.out.println("Integers: " + list);
    }
}

Почему компилятор запрещает такую перегрузку?

Причина кроется в механизме стирания типов (Type Erasure):

Дженерики служат только для статической проверки типов компилятором javac.
В процессе компиляции параметры дженериков отбрасываются: и List<String>, и List<Integer> превращаются в «сырой» тип List.
На уровне байт-кода JVM оба метода получают абсолютно идентичный дескриптор: void print(List list).
Поскольку JVM не допускает наличия в одном классе двух методов с одинаковым именем и одинаковыми типами аргументов, компилятор пресекает эту попытку на этапе сборки.

🟡 Middle Level

Представление в байт-коде: Дескрипторы и атрибут Signature

В виртуальной машине Java (JVM) методы идентифицируются именем и дескриптором метода (JVMS §4.3.3):

Сигнатура метода void print(List<String> list) после стирания получает дескриптор:
```
(Ljava/util/List;)V
```
Сигнатура метода void print(List<Integer> list) получает точно такой же дескриптор:
```
(Ljava/util/List;)V
```

Если бы компилятор попытался записать оба метода в структуру methods[] class-файла, верификатор байт-кода JVM отклонил бы класс с ошибкой ClassFormatError: Duplicate method name&signature.

А как же метаданные дженериков?

Компилятор сохраняет информацию о дженериках в специальном опциональном атрибуте класса Signature (JVMS §4.7.9):

// Метаданные для компилятора и Reflection API:
Signature: #15 // (Ljava/util/List<Ljava/lang/String;>;)V

Однако атрибут Signature используется исключительно компилятором при сборке зависимых модулей и рефлексивным API (Method.getGenericParameterTypes()). JVM при вызове инструкций invokevirtual или invokestatic полностью игнорирует атрибут Signature и диспетчеризирует вызов исключительно по первичному дескриптору (Ljava/util/List;)V.

Способы решения проблемы в архитектуре

Разные, говорящие имена методов (наиболее идиоматичный подход):

public void printStrings(List<String> list) { ... }
public void printIntegers(List<Integer> list) { ... }

Использование строго типизированных Record-обёрток (Value Objects):
```
public record StringPayload(List<String> items) {}
public record IntegerPayload(List<Integer> items) {}

public void print(StringPayload payload) { ... }
public void print(IntegerPayload payload) { ... }
```
У методов становятся разные дескрипторы: (Lcom/example/StringPayload;)V и (Lcom/example/IntegerPayload;)V.

Общий обобщенный метод с обработчиком:

public <T> void print(List<T> list, Consumer<T> printer) {
    list.forEach(printer);
}

🔴 Senior Level

Тонкости спецификации JLS и исключения

Спецификация языка Java (JLS §8.4.8.3) формулирует строгое правило:

«Объявление типа не может содержать два метода с одинаковым именем, если после применения стирания типов их сигнатуры становятся эквивалентными».

Однако важно различать типы параметров:

Коллекции с разными параметрами (List<String> vs List<Integer>) стираются в один и тот же тип (List) — перегрузка невозможна.
Параметры типов с разными границами (Bounds) стираются в разные типы — перегрузка разрешена!

// ✅ ЭТО СКОМПИЛИРУЕТСЯ И РАБОТАЕТ:
public class OverloadDemo {
    public <T extends Number> void process(T value) {
        System.out.println("Number: " + value);
    }

    public <T extends CharSequence> void process(T value) {
        System.out.println("CharSequence: " + value);
    }
}

Почему это работает?
Первый метод стирается до своей первой границы: void process(Number value) (дескриптор (Ljava/lang/Number;)V).
Второй метод стирается до void process(CharSequence value) (дескриптор (Ljava/lang/CharSequence;)V).
Поскольку дескрипторы байт-кода различаются, перегрузка полностью валидна.

Конфликт в иерархии интерфейсов (Multiple Inheritance Clash)

Класс не может одновременно реализовать два generic-интерфейса, если их методы после стирания имеют одинаковое имя и аргументы:

interface StringConsumer {
    void consume(List<String> list);
}

interface IntegerConsumer {
    void consume(List<Integer> list);
}

// ❌ Ошибка компиляции: 'consume(List<String>)' in 'StringConsumer' clashes with 
// 'consume(List<Integer>)' in 'IntegerConsumer'; both methods have same erasure
class Processor implements StringConsumer, IntegerConsumer {
    // Невозможно написать реализацию, удовлетворяющую обоим интерфейсам!
}

4 каверзных вопроса

1. Можно ли обойти ограничение перегрузки, если методы отличаются возвращаемым generic-типом (`List<String> get()` vs `List<Integer> get()`)?

Ответ:
В языке Java (JLS §8.4) перегрузка методов только по возвращаемому типу строго запрещена, даже без дженериков.
В байт-коде JVM дескриптор метода включает возвращаемый тип (()Ljava/util/List;), но компилятор javac не позволит объявить такие методы в одном исходном коде. Более того, после стирания оба метода возвращали бы List, что создало бы конфликт даже на уровне байт-кода.

2. Почему код `<T extends Number> void foo(T t)` и `<T extends String> void foo(T t)` разрешён, а `<T extends Number> void foo(List<T> t)` и `<T extends String> void foo(List<T> t)` запрещён?

Ответ:
Потому что стирание типов (Type Erasure) применяется к корневым типам аргументов:

В первом случае типы аргументов — это T. Стиранием T extends Number является Number, а T extends String — String. Байт-код получает методы foo(Number) и foo(String), чьи дескрипторы различаются.
Во втором случае аргументом обоих методов является List<T>. Стиранием любого типа List<...> является сырой тип List. В байт-код отправляются два метода с дескриптором foo(List), что вызывает name clash.

3. Что происходит, когда класс переопределяет generic-метод интерфейса с уточнением типа? Почему там нет конфликта erasure?

Ответ:
Когда класс реализует Comparable<String>, его метод int compareTo(String o) имеет дескриптор (Ljava/lang/String;)I. Однако интерфейс Comparable после стирания требует метод int compareTo(Object o) ((Ljava/lang/Object;)I).
В этом случае компилятор автоматически генерирует синтетический Bridge Method (ACC_BRIDGE, ACC_SYNTHETIC):

public int compareTo(java.lang.Object o) {
    return this.compareTo((java.lang.String) o); // checkcast + делегирование
}

В байт-коде сосуществуют оба метода, так как у них разные дескрипторы параметров (Object vs String), что обеспечивает полиморфизм.

4. Допустим ли хак с фиктивным параметром по умолчанию `void print(List<String> list, Void dummy)`? Какие у него минусы?

Ответ:
Да, добавление второго неиспользуемого параметра меняет сигнатуру метода в байт-коде и устраняет name clash:

public void print(List<String> list) { ... }
public void print(List<Integer> list, Void marker) { ... }

Однако этот трюк считается явным «антипаттерном»:

Загрязняет API вызывающего кода (приходится передавать print(integers, null)).
Снижает читаемость и вводит разработчиков в заблуждение.
Правильное архитектурное решение — дать методам осмысленные имена (printStrings, printIntegers) либо использовать типизированные структуры данных.

🎯 Шпаргалка для интервью

Прямой ответ: Перегрузка методов, отличающихся только дженерик-параметрами (например, List<String> и List<Integer>), невозможна из-за ошибки компиляции name clash: methods have the same erasure.
Причина: Type Erasure (стирание типов). В байт-коде оба метода получают одинаковый дескриптор (Ljava/util/List;)V. В JVM запрещено иметь два метода с одинаковым именем и типами аргументов в одном классе.
Роль атрибута Signature: Сохраняет generic-типы в .class для компилятора и рефлексии, но полностью игнорируется инструкциями вызова байт-кода JVM (invokevirtual).
Когда перегрузка с дженериками работает: Если параметры типов стираются в разные классы (например, <T extends Number> void f(T val) и <T extends String> void f(T val) стираются в f(Number) и f(String)).
Лучшие альтернативы: Осмысленные имена методов (saveUsers vs saveOrders) или обёртки-Records.