Метод має таке ж стирання, як і інший тип

Чому не можна законно мати наступні два методи в одному класі?

class Test{
   void add(Set<Integer> ii){}
   void add(Set<String> ss){}
}

Я розумію compilation error

Метод add (Set) має те ж додавання стирання (Set), як і інший метод типу Test.

хоча я можу обійти це, мені було цікаво, чому javac цього не любить.

Я бачу, що у багатьох випадках логіка цих двох методів була б дуже схожа і могла б бути замінена одиничною

public void add(Set<?> set){}

метод, але це не завжди так.

Це додатково дратує, якщо ви хочете мати два, constructorsякі приймають ці аргументи, тому що тоді ви не можете просто змінити ім'я одного з constructors.

Це правило призначене для уникнення конфліктів у застарілому коді, який все ще використовує необроблені типи.

Ось ілюстрація того, чому цього не було дозволено, накреслено з JLS. Припустимо, перед тим, як дженерики були представлені на Java, я написав такий код, як цей:

class CollectionConverter {
  List toList(Collection c) {...}
}

Ви розширюєте мій клас так, як це:

class Overrider extends CollectionConverter{
  List toList(Collection c) {...}
}

Після впровадження дженериків я вирішив оновити свою бібліотеку.

class CollectionConverter {
  <T> List<T> toList(Collection<T> c) {...}
}

Ви не готові робити будь-які оновлення, тому ви залишаєте Overriderклас наодинці. Щоб правильно змінити toList()метод, мовні дизайнери вирішили, що тип "необроблений" є "еквівалентним" будь-якому узагальненому типу. Це означає, що хоча ваш підпис методу вже формально не дорівнює підпису мого суперкласу, ваш метод все одно переосмислюється.

Тепер проходить час, і ви вирішите, що готові оновити свій клас. Але ви трохи викрутите, і замість того, щоб редагувати існуючий, необроблений toList()метод, ви додаєте новий метод на зразок цього:

class Overrider extends CollectionConverter {
  @Override
  List toList(Collection c) {...}
  @Override
  <T> List<T> toList(Collection<T> c) {...}
}

Через переоцінку еквівалентності вихідних типів обидва способи мають належну форму, щоб перекрити toList(Collection<T>)метод. Але звичайно, компілятору потрібно вирішити єдиний метод. Щоб усунути цю неоднозначність, класам заборонено використовувати декілька методів, які є еквівалентними, тобто декілька методів із тими ж параметрами після стирання.

Ключовим є те, що це мовне правило, розроблене для підтримки сумісності зі старим кодом з використанням сировинних типів. Це не обмеження, що вимагається стиранням параметрів типу; оскільки дозвіл методу відбувається під час компіляції, додавання загальних типів до ідентифікатора методу було б достатнім.

Java-дженерики використовує стирання типу. Біт у кутових дужках ( <Integer>і <String>) видаляється, тож ви отримаєте два способи, що мають однакову підпис ( add(Set)ви бачите помилку). Це не дозволено, оскільки час виконання не знатиме, який використовувати для кожного випадку.

Якщо Java коли-небудь отримає вдосконалені дженерики, то ви могли б це зробити, але це, мабуть, зараз малоймовірно.

Це відбувається тому, що Java Generics реалізовані за допомогою типу Erasure .

Ваші методи будуть переведені під час компіляції на щось на зразок:

Дозвіл методу відбувається під час компіляції та не враховує параметрів типу. ( див. відповідь Еріксона )

void add(Set ii);
void add(Set ss);

Обидва методи мають однаковий підпис без параметрів типу, отже, помилка.

Проблема полягає в тому, що Set<Integer>і Set<String>насправді трактуються як SetСВМ. Вибір типу для набору (String або Integer у вашому випадку) - це лише синтаксичний цукор, який використовується компілятором. JVM не може розрізняти Set<String>та Set<Integer>.

Визначте єдиний метод без типу void add(Set ii){}

Ви можете згадати тип під час виклику методу на основі вашого вибору. Він буде працювати для будь-якого типу набору.

Можливо, компілятор переводить Set (Integer) у Set (Object) у байт-код Java. У цьому випадку Set (Integer) буде використовуватися лише на фазі компіляції для перевірки синтаксису.

Я наткнувся на це, коли спробував написати щось на кшталт: Continuable<T> callAsync(Callable<T> code) {....} і Continuable<Continuable<T>> callAsync(Callable<Continuable<T>> veryAsyncCode) {...} вони стали для компілятора 2 визначеннями Continuable<> callAsync(Callable<> veryAsyncCode) {...}

Стирання типу буквально означає стирання інформації аргументів типу з дженерики. Це ДУЖЕ дратує, але це обмеження, яке буде з Java протягом певного часу. Для випадку конструкторів не дуже багато можна зробити, наприклад, 2 нові підкласи, спеціалізовані з різними параметрами в конструкторі. Або використовувати замість цього способи ініціалізації ... (віртуальні конструктори?) З різними іменами ...

подібні операційні методи перейменування допоможуть, як

class Test{
   void addIntegers(Set<Integer> ii){}
   void addStrings(Set<String> ss){}
}

Або з деякими більш описовими іменами, самодокументування таких випадків, як-небудь addNamesта addIndexesтаких.