Sta ereditando da una matrice primitiva impossibile dalla prospettiva della JVM?

Question

Beh il mio dubbio è questo:

In Java, è annullato a ereditare da una matrice, vale a dire, non si può fare cose come:

class FloatVec extends float[] 
{ 
    // Vector methods. 
} 

FloatVec somevec = new FloatVec()[] { 1, 2, 3 }; // With array initializer. 

O ancora meglio:

class FloatVec3 extends float[3] 
{ 
    // Regular accessor. 
    public float getX() { 
     return this[0]; 
    } 
    // Or say, make it the 'this' implicit like with other fields: 
    public void setVec(float x, float y, float z) { 
     [0] = x; 
     [1] = y; 
     [2] = z; 
    } 
    // And specific vec3 methods like: 
    public float dotProduct() { 
     float x = this[0]; 
     float y = this[1]; 
     float z = this[2]; 
     return x * x + y * y + z * z; 
    } 
} 

Ma gli array implementano effettivamente un'interfaccia specifica e sono considerati oggetti. cioè, ci si aspetta che le istanze dell'array siano gli stessi metodi esposti da Object, più un campo array specifico, il campo 'lunghezza' finale.

Quindi la mia domanda sono, anche se il linguaggio Java non consente questo utilizzo:

• Potrebbe essere implementato nella JVM senza troppi cambiamenti?

• La JVM tratta gli array come qualsiasi oggetto con una classe da cui si può ereditare?

• La JVM tratta gli array come enumerazioni, ovvero rendendo gli oggetti array ereditari automaticamente da una classe di array definita?

• La classe dell'array è definita da qualche parte in modo da poter essere ereditata?

Answer 1

Potrebbe essere implementato nella JVM senza troppe modifiche?

No. Le modifiche sarebbero enormi. Avrebbero impatto sull'intera catena di strumenti Java e anche su un enorme corpo di codice di terze parti che funziona al livello di astrazione JLS/JVM o al di sotto.

Non c'è nulla che ti impedisca di scaricare il codice sorgente (OpenJDK) e provare a farlo da solo come esperimento. Ma le probabilità che ciò accada nel reale Java sono (IMO) estremamente piccole.

Ho elencato solo alcuni dei problemi tecnici nella parte inferiore. Sono sicuro che ce ne sono altri.

La JVM tratta gli array come qualsiasi oggetto con una classe da cui si può ereditare?

No.

tipi Array in Java forniscono un piccolo numero di metodi. (I metodi sono getClass, hashCode, toString, clone, wait, notify e notifyAll ... come da Object API.)

quanto ne so, le implementazioni attuali di questi metodi sono forniti dai metodi nativi definiti di java.lang.Object. Ma poiché il JLS non ti permette di scrivere codice che eredita da un array, la specifica JVM non è necessario a fornire un modo per implementare tale codice. E, in pratica, non è così.

La JVM considera gli array come enumerazioni, ovvero rendendo gli oggetti array ereditari automaticamente da una classe di array definita?

No. I tipi di array implicitamente ereditano da java.lang.Object.

La classe dell'array è definita da qualche parte in modo da poter essere ereditata?

Non esiste tale classe. I tipi di matrice ereditano implicitamente da Object.

---

A livello spec JVM, ci sono un paio di principali ostacoli per rendere array più "classe-like":

• La rappresentazione "tipo stringa" di un tipo di matrice ("[ elem-type ") menziona solo l'elemento. Il vero tipo di array non ha nome e se lo ha fatto allora "Lname;" la rappresentazione è che dice che questa è una classe regolare, non un tipo di matrice.

• Le matrici vengono create da speciali istruzioni JVM che forniscono il tipo di elemento come un operando non il tipo di matrice.

E oltre a questo, un'implementazione JVM assumerà le cose su come funzionano gli array al fine di implementarli in modo efficiente. Anche se (secondo il JLS) sembra teoricamente possibile utilizzare un'istruzione invoke per chiamare un metodo non standard su un array, un interprete JVM o un compilatore JIT non saprebbero cosa farne ... anche se si in qualche modo riuscito a intrufolare il invoke oltre il caricatore di classe e verificatore.

Una volta superato questo, il problema è che se gli array possono essere dichiarati con superclassi definite dall'utente, allora tali superclassi potrebbero (presumibilmente) essere in grado di avere variabili di istanza. Ma ciò implica che le specifiche JVM deve cambiare in modo che:

• i nodi mucchio per le matrici possono contenere variabili di istanza così come la matrice stessa,

• le istruzioni di caricamento campo e store regolari lavorare su oggetti array e oggetti reculari,

• e così via.

Come si può vedere, questa "piccola estensione" svela un sacco di altre decisioni di progettazione nella JVM.

Answer 2

Condivide la JVM per trattamento di array come un qualsiasi oggetto con una classe che può essere ereditato da?

Ogni tipo di matrice primitiva ha effettivamente una classe. Ad esempio, un int[] è in realtà un'istanza di int[].class e un float[] è un'istanza di float[].class. (JLS 10.8) Puoi vedere nel tuo esempio di codice che queste classi non possono essere ereditate da.

La JVM considera gli array come enumerazioni, ovvero rendendo gli oggetti array ereditari automaticamente da una classe di array definita?

Sì, se si hanno due int[] array, dire a e b, quindi a.getClass() == b.getClass().

La classe dell'array è definita da qualche parte in modo da poter essere ereditata?

Come si può vedere nel proprio esempio di codice, queste classi non possono essere ereditate da. Non hanno codice sorgente e sono creati dalla JVM stessa, come detto in this other answer along with a code example.

Potrebbe essere implementato nella JVM senza troppe modifiche?

Questa domanda non rientra nell'ambito di Stack Overflow ed è molto soggettiva.

Answer 3

Il più vicino che si potrebbe arrivare a questo in Java è il progetto ObjectLayout di Gil Tene - http://objectlayout.org/ - questo è ancora una lunga strada da fare in Java, ma è possibile che questo renderà più come parte di Java 9