Perché dovrei preoccuparmi che Java non abbia generici reificati?

Questa è emersa come una domanda che ho posto di recente in un'intervista come qualcosa che il candidato desiderava vedere aggiunto al linguaggio Java. È comunemente identificato come un dolore il fatto che Java non abbia reificato i generici ma, se spinto, il candidato non poteva effettivamente dirmi il tipo di cose che avrebbe potuto ottenere se fossero lì.

Ovviamente poiché i tipi grezzi sono consentiti in Java (e i controlli non sicuri), è possibile sovvertire i generici e finire con un List<Integer>che (ad esempio) contiene effettivamente Strings. Questo chiaramente potrebbe essere reso impossibile se le informazioni sul tipo fossero reificate; ma dev'esserci di più !

Le persone potrebbero pubblicare esempi di cose che vorrebbero davvero fare , se fossero disponibili farmaci generici reificati? Voglio dire, ovviamente potresti ottenere il tipo di a Listin fase di esecuzione, ma cosa faresti con esso?

public <T> void foo(List<T> l) {
   if (l.getGenericType() == Integer.class) {
       //yeah baby! err, what now?

EDIT : Un rapido aggiornamento a questo dato che le risposte sembrano principalmente essere preoccupate per la necessità di passare a Classcome parametro (ad esempio EnumSet.noneOf(TimeUnit.class)). Stavo cercando qualcosa di simile a dove questo non è possibile . Per esempio:

List<?> l1 = api.gimmeAList();
List<?> l2 = api.gimmeAnotherList();

if (l1.getGenericType().isAssignableFrom(l2.getGenericType())) {
    l1.addAll(l2); //why on earth would I be doing this anyway?

Dalle poche volte in cui mi sono imbattuto in questo "bisogno", alla fine si riduce a questo costrutto:

public class Foo<T> {

    private T t;

    public Foo() {
        this.t = new T(); // Help?
    }

}

Funziona in C # presupponendo che Tabbia un costruttore predefinito . Puoi anche ottenere il tipo di runtime da typeof(T)e ottenere i costruttori da Type.GetConstructor().

La soluzione Java comune sarebbe passare l' Class<T>argomento as.

public class Foo<T> {

    private T t;

    public Foo(Class<T> cls) throws Exception {
        this.t = cls.newInstance();
    }

}

(non deve necessariamente essere passato come argomento del costruttore, poiché va bene anche un argomento del metodo, quanto sopra è solo un esempio, anche il try-catch viene omesso per brevità)

Per tutti gli altri costrutti di tipo generico, il tipo effettivo può essere facilmente risolto con un po 'di riflessione. Le seguenti domande e risposte illustrano i casi d'uso e le possibilità:

• Ottieni un tipo generico di java.util.List
• Come ottenere il tipo generico in fase di esecuzione?
• Ottieni il tipo effettivo di argomento di tipo generico sulla superclasse astratta

La cosa che più comunemente mi morde è l'incapacità di sfruttare l'invio multiplo su più tipi generici. Quanto segue non è possibile e ci sono molti casi in cui sarebbe la soluzione migliore:

public void my_method(List<String> input) { ... }
public void my_method(List<Integer> input) { ... }

Mi viene in mente la sicurezza dei tipi . Il downcasting a un tipo parametrizzato sarà sempre pericoloso senza generici reificati:

List<String> myFriends = new ArrayList();
myFriends.add("Alice");
getSession().put("friends", myFriends);
// later, elsewhere
List<Friend> myFriends = (List<Friend>) getSession().get("friends");
myFriends.add(new Friend("Bob")); // works like a charm!
// and so...
List<String> myFriends = (List<String>) getSession().get("friends");
for (String friend : myFriends) print(friend); // ClassCastException, wtf!? 

Inoltre, le astrazioni perderebbero meno , almeno quelle che potrebbero essere interessate alle informazioni di runtime sui loro parametri di tipo. Oggi, se hai bisogno di qualsiasi tipo di informazione di runtime sul tipo di uno dei parametri generici, devi trasmetterla anche tu Class. In questo modo, la tua interfaccia esterna dipende dalla tua implementazione (se usi RTTI per i tuoi parametri o meno).

Saresti in grado di creare array generici nel tuo codice.

public <T> static void DoStuff() {
    T[] myArray = new T[42]; // No can do
}

Questa è una vecchia domanda, ci sono un sacco di risposte, ma penso che le risposte esistenti non siano nel segno.

"reificato" significa solo reale e di solito significa solo l'opposto del tipo di cancellazione.

Il grosso problema relativo a Java Generics:

• Questo orribile requisito di boxe e disconnessione tra primitive e tipi di riferimento. Questo non è direttamente correlato alla reificazione o alla cancellazione del tipo. C # / Scala risolve questo problema.
• Nessun tipo di auto. JavaFX 8 ha dovuto rimuovere i "builder" per questo motivo. Assolutamente niente a che fare con la cancellazione del tipo. Scala risolve questo problema, non sono sicuro di C #.
• Nessuna varianza del tipo lato dichiarazione. C # 4.0 / Scala hanno questo. Assolutamente niente a che fare con la cancellazione del tipo.
• Non posso sovraccaricare void method(List<A> l)e method(List<B> l). Ciò è dovuto alla cancellazione del tipo, ma è estremamente meschino.
• Nessun supporto per la riflessione del tipo di runtime. Questo è il cuore della cancellazione dei caratteri. Se ti piacciono i compilatori super avanzati che verificano e dimostrano la maggior parte della logica del tuo programma in fase di compilazione, dovresti usare la riflessione il meno possibile e questo tipo di cancellazione del tipo non dovrebbe disturbarti. Se ti piace una programmazione di tipo più irregolare, scripty e dinamica e non ti interessa tanto che un compilatore dimostri quanto più possibile la tua logica corretta, allora vuoi una migliore riflessione e correggere la cancellazione del tipo è importante.

La serializzazione sarebbe più semplice con la reificazione. Quello che vorremmo è

deserialize(thingy, List<Integer>.class);

Quello che dobbiamo fare è

deserialize(thing, new TypeReference<List<Integer>>(){});

sembra brutto e funziona in modo strano.

Ci sono anche casi in cui sarebbe davvero utile dire qualcosa di simile

public <T> void doThings(List<T> thingy) {
    if (T instanceof Q)
      doCrazyness();
  }

Queste cose non mordono spesso, ma mordono quando accadono.

La mia esposizione a Java Geneircs è piuttosto limitata e, a parte i punti già menzionati da altre risposte, c'è uno scenario spiegato nel libro Java Generics and Collections , di Maurice Naftalin e Philip Walder, dove i generici reificati sono utili.

Poiché i tipi non sono modificabili, non è possibile avere eccezioni parametrizzate.

Ad esempio la dichiarazione del modulo sottostante non è valida.

class ParametericException<T> extends Exception // compile error

Questo perché la clausola catch controlla se l'eccezione generata corrisponde a un determinato tipo. Questo controllo è uguale al controllo eseguito dal test di istanza e poiché il tipo non è modificabile, la forma di dichiarazione sopra riportata non è valida.

Se il codice precedente fosse valido, sarebbe stata possibile gestire le eccezioni nel modo seguente:

try {
     throw new ParametericException<Integer>(42);
} catch (ParametericException<Integer> e) { // compile error
  ...
}

Il libro menziona anche che se i generici Java sono definiti in modo simile al modo in cui sono definiti i modelli C ++ (espansione), può portare a un'implementazione più efficiente poiché offre maggiori opportunità di ottimizzazione. Ma non offre alcuna spiegazione più di questo, quindi qualsiasi spiegazione (suggerimento) da parte di persone informate sarebbe utile.

Gli array probabilmente funzionerebbero molto meglio con i generici se fossero reificati.

Ho un wrapper che presenta un set di risultati jdbc come iteratore, (significa che posso testare le operazioni originate dal database molto più facilmente attraverso l'inserimento delle dipendenze).

L'API assomiglia Iterator<T> dove T è un tipo che può essere costruito utilizzando solo stringhe nel costruttore. L'iteratore quindi esamina le stringhe restituite dalla query sql e quindi cerca di abbinarle a un costruttore di tipo T.

Nell'attuale modo in cui vengono implementati i generici, devo anche passare alla classe degli oggetti che creerò dal mio gruppo di risultati. Se ho capito bene, se i generici fossero reificati, potrei semplicemente chiamare T.getClass () per ottenere i suoi costruttori, e quindi non dover eseguire il cast del risultato di Class.newInstance (), che sarebbe molto più ordinato.

Fondamentalmente, penso che renda più semplice la scrittura di API (al contrario della semplice scrittura di un'applicazione), perché puoi dedurre molto di più dagli oggetti, e quindi sarà necessaria meno configurazione ... Non ho apprezzato le implicazioni delle annotazioni fino a quando non ho li ho visti usati in cose come spring o xstream invece che in risme di configurazione.

Una cosa carina sarebbe evitare la boxe per i tipi primitivi (valore). Ciò è in qualche modo correlato al reclamo sull'array sollevato da altri e nei casi in cui l'uso della memoria è limitato, potrebbe effettivamente fare una differenza significativa.

Esistono anche diversi tipi di problemi durante la scrittura di un framework in cui è importante essere in grado di riflettere sul tipo parametrizzato. Ovviamente questo può essere aggirato passando un oggetto di classe in runtime, ma questo oscura l'API e pone un ulteriore fardello sull'utente del framework.

Non è che otterrai qualcosa di straordinario. Sarà solo più semplice da capire. La cancellazione del tipo sembra un momento difficile per i principianti e alla fine richiede la comprensione del modo in cui funziona il compilatore.

La mia opinione è che i generici siano semplicemente un extra che consente di risparmiare un sacco di casting ridondanti.

Qualcosa che tutte le risposte qui hanno perso che è costantemente un mal di testa per me è che poiché i tipi vengono cancellati, non puoi ereditare due volte un'interfaccia generica. Questo può essere un problema quando si desidera creare interfacce a grana fine.

    public interface Service<KEY,VALUE> {
           VALUE get(KEY key);
    }

    public class PersonService implements Service<Long, Person>,
        Service<String, Person> //Can not do!!

Eccone uno che mi ha catturato oggi: senza reificazione, se scrivi un metodo che accetta un elenco varargs di elementi generici ... i chiamanti possono PENSARE di non essere tipizzati, ma passano accidentalmente qualsiasi vecchia rozza e fanno saltare in aria il tuo metodo.

Sembra improbabile che ciò accada? ... Certo, finché ... non usi Class come tipo di dati. A questo punto, il chiamante ti invierà volentieri molti oggetti Class, ma un semplice errore di battitura ti invierà oggetti Class che non aderiscono a T e si verificherà un disastro.

(NB: potrei aver commesso un errore qui, ma cercando su Google "generics varargs", quanto sopra sembra essere proprio quello che ti aspetteresti. La cosa che rende questo un problema pratico è l'uso di Class, credo - i chiamanti sembrano stare meno attenti :()

Ad esempio, sto usando un paradigma che utilizza gli oggetti Class come chiave nelle mappe (è più complesso di una semplice mappa, ma concettualmente è quello che sta succedendo).

ad esempio, funziona alla grande in Java Generics (esempio banale):

public <T extends Component> Set<UUID> getEntitiesPossessingComponent( Class<T> componentType)
    {
        // find the entities that are mapped (somehow) from that class. Very type-safe
    }

es. senza reificazione in Java Generics, questo accetta QUALSIASI oggetto "Classe". Ed è solo una piccola estensione del codice precedente:

public <T extends Component> Set<UUID> getEntitiesPossessingComponents( Class<T>... componentType )
    {
        // find the entities that are mapped (somehow) to ALL of those classes
    }

I metodi di cui sopra devono essere scritti migliaia di volte in un singolo progetto, quindi la possibilità di errore umano diventa alta. Il debug degli errori si sta dimostrando "non divertente". Attualmente sto cercando di trovare un'alternativa, ma non ho molte speranze.