Metoda ma takie samo usunięcie jak inna metoda w typie

Dlaczego posiadanie następujących dwóch metod w tej samej klasie jest niezgodne z prawem?

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

Rozumiem compilation error

Metoda add (Set) ma to samo dodanie kasowania (Set), co inna metoda w teście typu.

chociaż mogę sobie z tym poradzić, zastanawiałem się, dlaczego javac tego nie lubi.

Widzę, że w wielu przypadkach logika tych dwóch metod byłaby bardzo podobna i mogłaby zostać zastąpiona jedną

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

metoda, ale nie zawsze tak jest.

Jest to szczególnie denerwujące, jeśli chcesz mieć dwa, constructorsktóre biorą te argumenty, ponieważ wtedy nie możesz po prostu zmienić nazwy jednego z nich constructors.

Ta reguła ma na celu uniknięcie konfliktów w starszym kodzie, który nadal używa typów raw.

Oto przykład, dlaczego nie było to dozwolone, zaczerpnięty z JLS. Załóżmy, że przed wprowadzeniem generics do Javy napisałem taki kod:

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

Rozszerzasz moją klasę w ten sposób:

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

Po wprowadzeniu ogólnych, postanowiłem zaktualizować swoją bibliotekę.

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

Nie jesteś gotowy na żadne aktualizacje, więc zostaw Overriderklasę w spokoju. Aby poprawnie przesłonić toList()metodę, projektanci języków zdecydowali, że typ surowy jest „zastępujący odpowiednik” dla dowolnego generowanego typu. Oznacza to, że chociaż podpis twojej metody nie jest już formalnie równy podpisowi mojej nadklasy, twoja metoda wciąż zastępuje.

Teraz czas mija i decydujesz, że jesteś gotowy, aby zaktualizować swoją klasę. Ale trochę spieprzysz i zamiast edytować istniejącą, surową toList()metodę, dodajesz nową metodę taką:

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

Z powodu zastąpienia równoważności typów surowych obie metody są w prawidłowej formie, aby zastąpić toList(Collection<T>)metodę. Ale oczywiście kompilator musi rozwiązać jedną metodę. Aby wyeliminować tę dwuznaczność, klasy nie mogą mieć wielu metod, które są równoważne z nadpisaniem - to znaczy wielu metod z tymi samymi typami parametrów po skasowaniu.

Kluczem jest to, że jest to reguła językowa zaprojektowana w celu zachowania zgodności ze starym kodem używającym typów raw. Nie jest to ograniczenie wymagane przez usunięcie parametrów typu; ponieważ rozpoznawanie metod zachodzi w czasie kompilacji, dodanie typów ogólnych do identyfikatora metody byłoby wystarczające.

Generics Java używa usuwania typu. Bit w nawiasach kątowych ( <Integer>i <String>) zostaje usunięty, więc otrzymujesz dwie metody o identycznej sygnaturze ( add(Set)widoczne w błędzie). Jest to niedozwolone, ponieważ środowisko wykonawcze nie wiedziałoby, którego użyć dla każdej sprawy.

Jeśli Java kiedykolwiek zostanie zweryfikowana, możesz to zrobić, ale prawdopodobnie teraz jest to mało prawdopodobne.

Wynika to z faktu, że Java Generics są implementowane za pomocą Type Erasure .

Twoje metody zostaną przetłumaczone w czasie kompilacji na coś takiego:

Rozdzielczość metody występuje w czasie kompilacji i nie uwzględnia parametrów typu. ( patrz odpowiedź Ericksona )

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

Obie metody mają tę samą sygnaturę bez parametrów typu, stąd błąd.

Problemem jest to, że Set<Integer>i Set<String>są właściwie traktowane jako Setz JVM. Wybranie typu dla zestawu (w twoim przypadku łańcuch lub liczba całkowita) to tylko cukier syntaktyczny używany przez kompilator. JVM nie może rozróżnić między Set<String>i Set<Integer>.

Zdefiniuj jedną metodę bez typu typu void add(Set ii){}

Możesz podać typ podczas wywoływania metody na podstawie swojego wyboru. Będzie działał dla każdego rodzaju zestawu.

Możliwe, że kompilator tłumaczy Set (Integer) na Set (Object) w kodzie bajtowym Java. W takim przypadku Set (liczba całkowita) byłby używany tylko w fazie kompilacji do sprawdzania składni.

Natknąłem się na to, gdy próbowałem napisać coś takiego: Continuable<T> callAsync(Callable<T> code) {....} i Continuable<Continuable<T>> callAsync(Callable<Continuable<T>> veryAsyncCode) {...} stały się dla kompilatora 2 definicjami Continuable<> callAsync(Callable<> veryAsyncCode) {...}

Kasowanie typu dosłownie oznacza kasowanie informacji o argumentach typu z nazw ogólnych. Jest to BARDZO denerwujące, ale jest to ograniczenie, które będzie obowiązywać przez pewien czas w Javie. W przypadku konstruktorów niewiele można zrobić, na przykład 2 nowe podklasy specjalizujące się w różnych parametrach w konstruktorze. Lub zamiast tego użyj metod inicjowania ... (wirtualnych konstruktorów?) O różnych nazwach ...

w przypadku podobnych metod operacji pomocna byłaby zmiana nazwy, np

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

Lub z kilkoma bardziej opisowymi nazwami, samodokumentującymi dla przypadków oyu, takich jak addNamesi addIndexestakich.