Cosa c'è di sbagliato con i generici di Java? [chiuso]

Ho visto diverse volte su questo sito post che denigrano l'implementazione di generici da parte di Java. Ora posso onestamente dire che non ho avuto problemi con il loro utilizzo. Tuttavia, non ho tentato di creare una classe generica da solo. Quindi, quali sono i tuoi problemi con il supporto generico di Java?

L'implementazione generica di Java utilizza la cancellazione del tipo . Ciò significa che le raccolte generiche fortemente tipizzate sono effettivamente di tipo Objectin fase di esecuzione. Questo ha alcune considerazioni sulle prestazioni in quanto significa che i tipi primitivi devono essere inscatolati quando aggiunti a una raccolta generica. Naturalmente i vantaggi della correttezza del tipo di tempo di compilazione superano la stupidità generale della cancellazione del tipo e della focalizzazione ossessiva sulla retrocompatibilità.

Osservare che le risposte già fornite si concentrano sulla combinazione di Java-the-language, JVM e Java Class Library.

Non c'è niente di sbagliato nei generici di Java per quanto riguarda Java-the-language. Come descritto in C # vs generici Java , i generici Java sono praticamente a livello di linguaggio ¹ .

La cosa non ottimale è che la JVM non supporta direttamente i generici, il che ha diverse conseguenze importanti:

• le parti relative alla riflessione della Libreria di classi non possono esporre le informazioni complete sul tipo disponibili in Java-the-language
• è prevista una penalità per le prestazioni

Suppongo che la distinzione che sto facendo sia pedante poiché Java-the-language è ubiquamente compilato con JVM come destinazione e Java Class Library come libreria principale.

¹ Con la possibile eccezione dei caratteri jolly, che si ritiene rendere l'inferenza del tipo indecidibile nel caso generale. Questa è una grande differenza tra generici C # e Java che non è menzionata molto spesso. Grazie, antimonio.

La solita critica è la mancanza di reificazione. Vale a dire che gli oggetti in fase di runtime non contengono informazioni sui loro argomenti generici (sebbene le informazioni siano ancora presenti su campi, metodo, costruttori e classe estesa e interfacce). Questo significa che potresti lanciare, diciamo, ArrayList<String>a List<File>. Il compilatore ti avvertirà, ma ti avvertirà anche se lo ArrayList<String>assegni a un Objectriferimento e poi lo cast List<String>. I lati positivi sono che con i generici probabilmente non dovresti fare il casting, le prestazioni sono migliori senza i dati non necessari e, ovviamente, la compatibilità con le versioni precedenti.

Alcune persone si lamentano del fatto che non è possibile sovraccaricare sulla base di argomenti generici ( void fn(Set<String>)e void fn(Set<File>)). È necessario invece utilizzare nomi di metodi migliori. Si noti che questo sovraccarico non richiederebbe la reificazione, poiché il sovraccarico è un problema statico durante la compilazione.

I tipi primitivi non funzionano con i generici.

I caratteri jolly e i limiti sono piuttosto complicati. Sono molto utili Se Java preferisse l'immutabilità e le interfacce Tell-Don't-Ask, allora i generici sul lato della dichiarazione piuttosto che sul lato dell'uso sarebbero più appropriati.

I generici Java fanno schifo perché non puoi fare quanto segue:

public class AsyncAdapter<Parser,Adapter> extends AsyncTask<String,Integer,Adapter> {
    proptected Adapter doInBackground(String... keywords) {
      Parser p = new Parser(keywords[0]); // this is an error
      /* some more stuff I was hoping for but couldn't do because
         the compiler wouldn't let me
      */
    }
}

Non è necessario macellare ogni classe nel codice sopra per farlo funzionare come dovrebbe se i generici fossero in realtà parametri di classe generici.

• gli avvisi del compilatore per la mancanza di parametri generici che non servono a nulla rendono la lingua inutilmente dettagliata, ad es public String getName(Class<?> klazz){ return klazz.getName();}

• I generici non giocano bene con gli array

• Le informazioni perse sul tipo rendono la riflessione un casino di casting e nastro adesivo.

Penso che altre risposte abbiano detto questo in una certa misura, ma non molto chiaramente. Uno dei problemi con i generici sta perdendo i tipi generici durante il processo di riflessione. Quindi per esempio:

List<String> arr = new ArrayList<String>();
assertTrue( ArrayList.class, arr.getClass() );
TypeVarible[] types = arr.getClass().getTypedVariables();

Sfortunatamente, i tipi restituiti non possono dirti che i tipi generici di arr sono String. È una differenza sottile, ma è importante. Poiché arr viene creato in fase di esecuzione, i tipi generici vengono cancellati in fase di esecuzione, quindi non è possibile capirlo. Come alcuni hanno affermato ArrayList<Integer>sembra lo stesso ArrayList<String>dal punto di vista della riflessione.

Questo potrebbe non importare all'utente di Generics, ma diciamo che volevamo creare un framework di fantasia che usasse la riflessione per capire cose fantasiose su come l'utente ha dichiarato i tipi generici concreti di un'istanza.

Factory<MySpecialObject> factory = new Factory<MySpecialObject>();
MySpecialObject obj = factory.create();

Diciamo che volevamo che una fabbrica generica creasse un'istanza MySpecialObjectperché quello è il tipo generico concreto che abbiamo dichiarato per questa istanza. Bene, la classe Factory non può interrogarsi per scoprire il tipo concreto dichiarato per questa istanza perché Java li ha cancellati.

Nei generici di .Net puoi farlo perché in fase di esecuzione l'oggetto sa che sono tipi generici perché il compilatore lo ha rispettato nel file binario. Con le cancellazioni Java non può farlo.

Potrei dire alcune cose positive sui generici, ma non era questa la domanda. Potrei lamentarmi che non sono disponibili in fase di esecuzione e non funzionano con le matrici, ma questo è stato menzionato.

Un grande fastidio psicologico: ogni tanto mi trovo in situazioni in cui i generici non possono essere fatti funzionare. (Le matrici sono l'esempio più semplice.) E non riesco a capire se i generici non possono fare il lavoro o se sono solo stupido. Odio che. Qualcosa come i generici dovrebbe funzionare sempre. Ogni altra volta che non riesco a fare quello che voglio usando Java-the-language, so che il problema sono io e so che se continuo a spingere, alla fine ci arriverò. Con i generici, se divento troppo persistente, posso perdere molto tempo.

Ma il vero problema è che i generici aggiungono troppa complessità per un guadagno troppo piccolo. Nei casi più semplici può impedirmi di aggiungere una mela a un elenco contenente automobili. Belle. Ma senza generici questo errore genererebbe una ClassCastException molto veloce in fase di esecuzione con poco tempo perso. Se aggiungo un'auto con un seggiolino per bambini con dentro un bambino, ho bisogno di un avviso in fase di compilazione che l'elenco è solo per le auto con seggiolini per bambini che contengono scimpanzé? Un elenco di semplici istanze di oggetti inizia a sembrare una buona idea.

Il codice generico può contenere molte parole e caratteri e occupare molto spazio extra e impiegare molto più tempo a leggere. Posso passare molto tempo a far funzionare tutto quel codice extra. Quando lo fa, mi sento follemente intelligente. Ho anche perso diverse ore o più del mio tempo e devo chiedermi se qualcun altro sarà mai in grado di capire il codice. Vorrei poterlo consegnare per la manutenzione a persone che sono meno intelligenti di me o che hanno meno tempo da perdere.

D'altra parte (sono rimasto un po 'ferito lì e sento il bisogno di fornire un po' di equilibrio), è bello quando si usano raccolte e mappe semplici per aggiungere, mettere e controllare quando sono scritte, e di solito non aggiunge molto complessità al codice ( se qualcun altro scrive la raccolta o la mappa) . E Java è migliore in questo rispetto a C #. Sembra che nessuna delle raccolte C # che voglio usare gestisca mai generici. (Ammetto di avere strani gusti nelle collezioni.)