Qual è il motivo per cui non riesco a creare tipi di array generici in Java?

Qual è il motivo per cui Java non ci consente di fare

private T[] elements = new T[initialCapacity];

Potrei capire .NET non ci ha permesso di farlo, poiché in .NET hai tipi di valore che in fase di runtime possono avere dimensioni diverse, ma in Java tutti i tipi di T saranno riferimenti a oggetti, quindi con le stesse dimensioni ( correggimi se sbaglio).

Qual è la ragione?

È perché gli array Java (a differenza dei generici) contengono, in fase di esecuzione, informazioni sul tipo di componente. Quindi è necessario conoscere il tipo di componente quando si crea l'array. Dato che non sai cosa Tè in fase di esecuzione, non puoi creare l'array.

Citazione:

Le matrici di tipi generici non sono consentite perché non sono valide. Il problema è dovuto all'interazione di array Java, che non sono staticamente validi ma sono controllati dinamicamente, con generici, che sono staticamente validi e non controllati dinamicamente. Ecco come è possibile sfruttare la scappatoia:

class Box<T> {
    final T x;
    Box(T x) {
        this.x = x;
    }
}

class Loophole {
    public static void main(String[] args) {
        Box<String>[] bsa = new Box<String>[3];
        Object[] oa = bsa;
        oa[0] = new Box<Integer>(3); // error not caught by array store check
        String s = bsa[0].x; // BOOM!
    }
}

Avevamo proposto di risolvere questo problema usando array staticamente sicuri (aka Variance) che era stato respinto per Tiger.

- Gafter

(Credo che sia Neal Gafter , ma non ne sono sicuro)

Guardalo nel contesto qui: http://forums.sun.com/thread.jspa?threadID=457033&forumID=316

Non riuscendo a fornire una soluzione decente, si finisce con qualcosa di peggio di IMHO.

Il lavoro comune è il seguente.

T[] ts = new T[n];

viene sostituito con (supponendo che T estende Object e non un'altra classe)

T[] ts = (T[]) new Object[n];

Preferisco il primo esempio, tuttavia più tipi accademici sembrano preferire il secondo, o semplicemente preferiscono non pensarci.

La maggior parte degli esempi del perché non si può semplicemente usare un Object [] si applicano ugualmente a List o Collection (che sono supportati), quindi li vedo come argomenti molto poveri.

Nota: questo è uno dei motivi per cui la libreria Collezioni non viene compilata senza avvisi. Se questo caso d'uso non può essere supportato senza avvertimenti, qualcosa è fondamentalmente rotto con il modello generico IMHO.

Le matrici sono covarianti

Si dice che le matrici siano covarianti, il che significa sostanzialmente che, date le regole del sottotipo di Java, una matrice di tipo T[]può contenere elementi di tipo To qualsiasi sottotipo di T. Per esempio

Number[] numbers = new Number[3];
numbers[0] = newInteger(10);
numbers[1] = newDouble(3.14);
numbers[2] = newByte(0);

Ma non solo, le regole del sottotipo di Java affermano anche che un array S[]è un sottotipo dell'array T[]se Sè un sottotipo di T, quindi qualcosa di simile è anche valido:

Integer[] myInts = {1,2,3,4};
Number[] myNumber = myInts;

Perché secondo le regole del sottotipo in Java, un array Integer[]è un sottotipo di un array Number[]perché Integer è un sottotipo di Number.

Ma questa regola di sottotitolo può portare a una domanda interessante: cosa accadrebbe se provassimo a farlo?

myNumber[0] = 3.14; //attempt of heap pollution

Quest'ultima riga verrà compilata correttamente, ma se eseguiamo questo codice, otterremmo un ArrayStoreExceptionperché stiamo cercando di inserire un doppio in un array intero. Il fatto che stiamo accedendo all'array tramite un riferimento numerico è irrilevante qui, ciò che conta è che l'array sia un array di numeri interi.

Ciò significa che possiamo ingannare il compilatore, ma non possiamo ingannare il sistema di tipi di runtime. E questo perché le matrici sono ciò che chiamiamo un tipo riutilizzabile. Ciò significa che al runtime Java sa che questo array è stato effettivamente istanziato come un array di numeri interi a cui si accede semplicemente tramite un riferimento di tipo Number[].

Quindi, come possiamo vedere, una cosa è il tipo reale dell'oggetto, un'altra cosa è il tipo di riferimento che usiamo per accedervi, giusto?

Il problema con Java Generics

Ora, il problema con i tipi generici in Java è che le informazioni sul tipo per i parametri del tipo vengono scartate dal compilatore dopo aver completato la compilazione del codice; pertanto queste informazioni sul tipo non sono disponibili in fase di esecuzione. Questo processo è chiamato cancellazione del tipo . Ci sono buoni motivi per implementare generici come questo in Java, ma questa è una lunga storia, e ha a che fare con la compatibilità binaria con codice preesistente.

Il punto importante qui è che dal momento che in fase di esecuzione non ci sono informazioni sul tipo, non c'è modo di garantire che non stiamo commettendo l'inquinamento da ammasso.

Consideriamo ora il seguente codice non sicuro:

List<Integer> myInts = newArrayList<Integer>();
myInts.add(1);
myInts.add(2);
List<Number> myNums = myInts; //compiler error
myNums.add(3.14); //heap polution

Se il compilatore Java non ci impedisce di farlo, il sistema dei tipi di runtime non può fermarci neanche, perché al momento dell'esecuzione non è possibile determinare che questo elenco dovrebbe essere un elenco di soli numeri interi. Il runtime Java ci consentirebbe di inserire ciò che vogliamo in questo elenco, quando dovrebbe contenere solo numeri interi, poiché quando è stato creato, è stato dichiarato come un elenco di numeri interi. Ecco perché il compilatore rifiuta la riga numero 4 perché non è sicuro e, se consentito, potrebbe infrangere i presupposti del sistema di tipi.

Pertanto, i progettisti di Java si sono assicurati di non poter ingannare il compilatore. Se non riusciamo a ingannare il compilatore (come possiamo fare con le matrici), non possiamo nemmeno ingannare il sistema di tipi di runtime.

Pertanto, diciamo che i tipi generici non sono riutilizzabili, poiché in fase di esecuzione non possiamo determinare la vera natura del tipo generico.

Ho saltato alcune parti di queste risposte, puoi leggere l'articolo completo qui: https://dzone.com/articles/covariance-and-contravariance

Il motivo per cui ciò è impossibile è che Java implementa i suoi generici esclusivamente a livello di compilatore e per ogni classe viene generato un solo file di classe. Questo si chiama Type Erasure .

In fase di runtime, la classe compilata deve gestire tutti i suoi usi con lo stesso bytecode. Quindi, new T[capacity]non avrei assolutamente idea di quale tipo debba essere istanziato.

La risposta è già stata fornita, ma se hai già un'istanza di T, puoi farlo:

T t; //Assuming you already have this object instantiated or given by parameter.
int length;
T[] ts = (T[]) Array.newInstance(t.getClass(), length);

Spero di poterti aiutare, Ferdi265

Il motivo principale è dovuto al fatto che gli array in Java sono covarianti.

C'è una buona panoramica qui .

Mi piace la risposta indirettamente data da Gafter . Tuttavia, propongo che sia sbagliato. Ho cambiato un po 'il codice di Gafter. Si compila e funziona per un po ', poi bombe dove Gafter aveva previsto

class Box<T> {

    final T x;

    Box(T x) {
        this.x = x;
    }
}

class Loophole {

    public static <T> T[] array(final T... values) {
        return (values);
    }

    public static void main(String[] args) {

        Box<String> a = new Box("Hello");
        Box<String> b = new Box("World");
        Box<String> c = new Box("!!!!!!!!!!!");
        Box<String>[] bsa = array(a, b, c);
        System.out.println("I created an array of generics.");

        Object[] oa = bsa;
        oa[0] = new Box<Integer>(3);
        System.out.println("error not caught by array store check");

        try {
            String s = bsa[0].x;
        } catch (ClassCastException cause) {
            System.out.println("BOOM!");
            cause.printStackTrace();
        }
    }
}

L'output è

I created an array of generics.
error not caught by array store check
BOOM!
java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
    at Loophole.main(Box.java:26)

Quindi mi sembra che tu possa creare tipi di array generici in Java. Ho frainteso la domanda?

So di essere un po 'in ritardo alla festa qui, ma ho pensato che potrei essere in grado di aiutare eventuali googler futuri poiché nessuna di queste risposte ha risolto il mio problema. La risposta di Ferdi265 ha aiutato immensamente però.

Sto cercando di creare il mio elenco collegato, quindi il seguente codice è quello che ha funzionato per me:

package myList;
import java.lang.reflect.Array;

public class MyList<TYPE>  {

    private Node<TYPE> header = null;

    public void clear() {   header = null;  }

    public void add(TYPE t) {   header = new Node<TYPE>(t,header);    }

    public TYPE get(int position) {  return getNode(position).getObject();  }

    @SuppressWarnings("unchecked")
    public TYPE[] toArray() {       
        TYPE[] result = (TYPE[])Array.newInstance(header.getObject().getClass(),size());        
        for(int i=0 ; i<size() ; i++)   result[i] = get(i); 
        return result;
    }


    public int size(){
         int i = 0;   
         Node<TYPE> current = header;
         while(current != null) {   
           current = current.getNext();
           i++;
        }
        return i;
    }  

Nel metodo toArray () si trova il modo di creare una matrice di tipo generico per me:

TYPE[] result = (TYPE[])Array.newInstance(header.getObject().getClass(),size());    

Nel mio caso, volevo semplicemente una serie di pile, qualcosa del genere:

Stack<SomeType>[] stacks = new Stack<SomeType>[2];

Poiché ciò non è stato possibile, ho usato il seguente come soluzione alternativa:

1. Creata una classe wrapper non generica attorno a Stack (ad esempio MyStack)
2. MyStack [] stacks = new MyStack [2] ha funzionato perfettamente

Brutto, ma Java è felice.

Nota: come menzionato da BrainSlugs83 nel commento alla domanda, è totalmente possibile avere array di generici in .NET

Dal tutorial Oracle :

Non è possibile creare matrici di tipi con parametri. Ad esempio, il seguente codice non viene compilato:

List<Integer>[] arrayOfLists = new List<Integer>[2];  // compile-time error

Il codice seguente mostra cosa succede quando si inseriscono tipi diversi in un array:

Object[] strings = new String[2];
strings[0] = "hi";   // OK
strings[1] = 100;    // An ArrayStoreException is thrown.

Se provi la stessa cosa con un elenco generico, ci sarebbe un problema:

Object[] stringLists = new List<String>[];  // compiler error, but pretend it's allowed
stringLists[0] = new ArrayList<String>();   // OK
stringLists[1] = new ArrayList<Integer>();  // An ArrayStoreException should be thrown,
                                            // but the runtime can't detect it.

Se fossero consentite matrici di elenchi parametrizzati, il codice precedente non genererebbe ArrayStoreException desiderato.

A me sembra molto debole. Penso che chiunque abbia una comprensione sufficiente dei generici, starebbe benissimo, e persino si aspetterebbe, che ArrayStoredException non venga lanciato in questo caso.

Deve esserci sicuramente un buon modo per aggirarlo (forse usando la riflessione), perché mi sembra che sia esattamente quello che ArrayList.toArray(T[] a)fa. Quoto:

public <T> T[] toArray(T[] a)

Restituisce un array contenente tutti gli elementi in questo elenco nell'ordine corretto; il tipo di runtime dell'array restituito è quello dell'array specificato. Se l'elenco si adatta all'array specificato, viene restituito al suo interno. In caso contrario, viene assegnato un nuovo array con il tipo di runtime dell'array specificato e le dimensioni di questo elenco.

Quindi un modo per aggirarlo sarebbe usare questa funzione, cioè creare uno ArrayListdegli oggetti desiderati nell'array, quindi usare toArray(T[] a)per creare l'array reale. Non sarebbe veloce, ma non hai menzionato le tue esigenze.

Qualcuno sa come toArray(T[] a)viene implementato?

È perché i generici sono stati aggiunti a java dopo averlo creato, quindi è un po 'goffo perché i produttori originali di java hanno pensato che quando si creava un array il tipo sarebbe stato specificato nella sua realizzazione. In modo che non funzioni con generici quindi devi fare E [] array = (E []) new Object [15]; Questo compila ma dà un avvertimento.

Se non possiamo istanziare array generici, perché la lingua ha tipi di array generici? Qual è il punto di avere un tipo senza oggetti?

L'unica ragione che mi viene in mente è varargs - foo(T...). Altrimenti avrebbero potuto cancellare completamente i tipi di array generici. (Beh, non avevano davvero bisogno di usare l'array per varargs, dato che varargs non esisteva prima della 1.5 . Questo è probabilmente un altro errore.)

Quindi è una bugia, puoi istanziare array generici, attraverso varargs!

Naturalmente, i problemi con le matrici generiche sono ancora reali, ad es

static <T> T[] foo(T... args){
    return args;
}
static <T> T[] foo2(T a1, T a2){
    return foo(a1, a2);
}

public static void main(String[] args){
    String[] x2 = foo2("a", "b"); // heap pollution!
}

Possiamo usare questo esempio per dimostrare effettivamente il pericolo dell'array generico .

D'altra parte, usiamo vararg generici da un decennio e il cielo non sta ancora calando. Quindi possiamo sostenere che i problemi vengono esagerati; non è un grosso problema. Se è consentita la creazione esplicita di array generici, avremo bug qua e là; ma siamo stati abituati ai problemi di cancellazione e possiamo conviverci.

E possiamo indicare di foo2confutare l'affermazione secondo cui le specifiche ci impediscono di risolvere i problemi da cui sostengono. Se Sun avesse avuto più tempo e risorse per 1,5 , credo che avrebbero potuto raggiungere una risoluzione più soddisfacente.

Come altri hanno già detto, puoi ovviamente creare alcuni trucchi .

Ma non è raccomandato

Poiché la cancellazione del tipo e, soprattutto, l' covariancearray in che consente solo un array di sottotipi può essere assegnato a un array di supertipi, il che ti costringe a utilizzare il cast di tipi espliciti quando tenti di ottenere il valore causando il runtime ClassCastExceptionche è uno degli obiettivi principali che i generici cercano di eliminare: controlli di tipo più forti al momento della compilazione .

Object[] stringArray = { "hi", "me" };
stringArray[1] = 1;
String aString = (String) stringArray[1]; // boom! the TypeCastException

Un esempio più diretto può essere trovato in Effective Java: Item 25 .

covarianza : una matrice di tipo S [] è un sottotipo di T [] se S è un sottotipo di T

Se la classe utilizza come tipo con parametri, può dichiarare una matrice di tipo T [], ma non può creare un'istanza diretta di tale matrice. Invece, un approccio comune è quello di creare un'istanza di una matrice di tipo Object [], quindi creare un cast restrittivo per digitare T [], come mostrato di seguito:

  public class Portfolio<T> {
  T[] data;
 public Portfolio(int capacity) {
   data = new T[capacity];                 // illegal; compiler error
   data = (T[]) new Object[capacity];      // legal, but compiler warning
 }
 public T get(int index) { return data[index]; }
 public void set(int index, T element) { data[index] = element; }
}

Prova questo:

List<?>[] arrayOfLists = new List<?>[4];