Чи можна перевантажувати методи, що відрізняються лише дженерик-параметрами

Причина криється в механізмі стирання типів (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 Tricky Questions

1. Чи можна обійти обмеження перевантаження, якщо методи відрізняються типом повернення з дженериком (`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.