Il metodo ha la stessa cancellazione di un altro metodo nel tipo

Perché non è legale avere i seguenti due metodi nella stessa classe?

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

Ottengo il compilation error

Il metodo add (Set) ha la stessa cancellazione (Set) di un altro metodo nel tipo Test.

mentre ci posso aggirare, mi chiedevo perché a javac non piacesse.

Vedo che in molti casi la logica di questi due metodi sarebbe molto simile e potrebbe essere sostituita da una singola

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

metodo, ma non è sempre così.

Questo è molto fastidioso se vuoi averne due constructorsche accettano questi argomenti perché non puoi semplicemente cambiare il nome di uno dei constructors.

Questa regola ha lo scopo di evitare conflitti nel codice legacy che utilizza ancora tipi non elaborati.

Ecco un esempio del perché ciò non era consentito, tratto dal JLS. Supponiamo, prima che i generici fossero introdotti a Java, ho scritto un codice come questo:

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

Estendi la mia classe, in questo modo:

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

Dopo l'introduzione dei farmaci generici, ho deciso di aggiornare la mia biblioteca.

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

Non sei pronto per effettuare aggiornamenti, quindi lasci la tua Overriderclasse da solo. Per sostituire correttamente iltoList() metodo, i progettisti del linguaggio hanno deciso che un tipo grezzo era "equivalente a sostituzione" di qualsiasi tipo generato. Ciò significa che sebbene la firma del tuo metodo non sia più formalmente uguale alla firma della mia superclasse, il tuo metodo ha ancora la precedenza.

Ora passa il tempo e decidi di essere pronto per aggiornare la tua classe. Ma fai un po 'di casino e invece di modificare il toList()metodo raw esistente, aggiungi un nuovo metodo come questo:

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

A causa dell'equivalenza di sostituzione dei tipi non elaborati, entrambi i metodi sono in una forma valida per ignorare il toList(Collection<T>)metodo. Ma ovviamente, il compilatore deve risolvere un singolo metodo. Per eliminare questa ambiguità, alle classi non è consentito disporre di più metodi che sono equivalenti a override, ovvero più metodi con gli stessi tipi di parametri dopo la cancellazione.

La chiave è che questa è una regola del linguaggio progettata per mantenere la compatibilità con il vecchio codice utilizzando tipi non elaborati. Non è una limitazione richiesta dalla cancellazione dei parametri di tipo; poiché la risoluzione del metodo si verifica in fase di compilazione, l'aggiunta di tipi generici all'identificatore del metodo sarebbe stata sufficiente.

I generici Java utilizzano la cancellazione del tipo. Il bit tra parentesi angolari ( <Integer>e <String>) viene rimosso, quindi si finirebbe con due metodi che hanno una firma identica (la add(Set)vedi nell'errore). Ciò non è consentito perché il runtime non saprebbe quale utilizzare per ciascun caso.

Se Java ottiene mai generici reificati, allora potresti farlo, ma probabilmente è improbabile ora.

Questo perché Java Generics è implementato con Type Erasure .

I tuoi metodi verrebbero tradotti, al momento della compilazione, in qualcosa del tipo:

La risoluzione del metodo si verifica in fase di compilazione e non considera i parametri di tipo. ( vedi la risposta di erickson )

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

Entrambi i metodi hanno la stessa firma senza i parametri di tipo, quindi l'errore.

Il problema è che Set<Integer>e in Set<String>realtà sono trattati come Setda JVM. La selezione di un tipo per il Set (String o Integer nel tuo caso) è solo lo zucchero sintattico utilizzato dal compilatore. La JVM non riesce a distinguere tra Set<String>e Set<Integer>.

Definire un singolo metodo senza digitare like void add(Set ii){}

Puoi menzionare il tipo mentre chiami il metodo in base alla tua scelta. Funzionerà con qualsiasi tipo di set.

Potrebbe essere possibile che il compilatore traduca Set (intero) in Set (oggetto) nel codice byte java. In tal caso, Set (Integer) verrebbe utilizzato solo in fase di compilazione per il controllo della sintassi.

Mi sono imbattuto in questo quando ho provato a scrivere qualcosa del genere: Continuable<T> callAsync(Callable<T> code) {....} e Continuable<Continuable<T>> callAsync(Callable<Continuable<T>> veryAsyncCode) {...} diventano per il compilatore le 2 definizioni di Continuable<> callAsync(Callable<> veryAsyncCode) {...}

La cancellazione del tipo significa letteralmente cancellare le informazioni sugli argomenti di tipo dai generici. Questo è MOLTO fastidioso, ma questa è una limitazione che sarà con Java per un po '. Per i costruttori non si può fare molto, ad esempio 2 nuove sottoclassi specializzate con parametri diversi nel costruttore. Oppure usa metodi di inizializzazione invece ... (costruttori virtuali?) Con nomi diversi ...

per metodi operativi simili, la ridenominazione sarebbe utile, ad esempio

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

O con alcuni nomi più descrittivi, di auto-documentazione per i casi Oyu, come addNamese addIndexeso tali.