MethodHandle - Di cosa si tratta?

Question

Sto studiando nuove funzionalità di JDK 1.7 e non riesco proprio a capire a cosa serve MethodHandle? Comprendo l'invocazione (diretta) del metodo statico (e l'uso dell'API di Core Reflection che è semplice in questo caso). Comprendo anche l'invocazione (diretta) del metodo virtuale (non statico, non finale) (e l'uso dell'API Core Reflection che richiede di passare attraverso la gerarchia della classe obj.getClass().getSuperclass()). L'invocazione del metodo non virtuale può essere trattata come caso speciale del precedente.

Sì, sono a conoscenza del problema di sovraccarico. Se vuoi invocare il metodo devi fornire la firma esatta. Non è possibile controllare il metodo sovraccarico in modo semplice.

Ma di cosa parla MethodHandle? L'API di Reflection consente di "guardare" gli interni dell'oggetto senza alcuna presunzione (come implementata l'interfaccia). È possibile ispezionare l'oggetto per qualche scopo. Ma cos'è progettato anche MethodHandle? Perché e quando dovrei usarlo?

UPDATE: Sto leggendo ora questo articolo http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html. In base a ciò, l'obiettivo principale è semplificare la vita dei linguaggi di script che vengono eseguiti in cima a JVM e non per Java Language stesso.

UPDATE-2: finisco di leggere il link qui sopra, alcuni citazione da lì:

La JVM sta per essere la migliore macchina virtuale per la creazione di linguaggi dinamici, perché già è un linguaggio dinamico VM. E InvokeDynamic, promuovendo linguaggi dinamici per cittadini JVM di prima classe, lo dimostrerà.

L'uso della riflessione per invocare metodi funziona alla grande ... tranne per alcuni problemi. Gli oggetti metodo devono essere recuperati da un tipo specifico e non possono essere creati in modo generale. < ...>

... l'invocazione riflessa è molto più lenta dell'invocazione diretta. Nel corso degli anni, la JVM è diventata davvero brava a rendere veloce l'invocazione riflessa. Le moderne JVM generano effettivamente un po 'di codice dietro le quinte per evitare una gran parte delle vecchie JVM gestite. Ma la semplice verità è che l'accesso riflesso attraverso qualsiasi numero di livelli sarà sempre più lento di una chiamata diretta, in parte perché il metodo "invoke" completamente generato deve controllare e ricontrollare il tipo di ricevitore, i tipi di argomenti, la visibilità e altri dettagli, ma anche perché gli argomenti devono essere tutti oggetti (quindi le primitive ricevono oggetti in box) e devono essere forniti come una matrice per coprire tutte le possibili entità (in modo che gli argomenti vengano ordinati in serie).

La differenza di prestazioni potrebbe non essere importante per una libreria che esegue alcune chiamate riflesse, soprattutto se tali chiamate servono principalmente a configurare dinamicamente una struttura statica in memoria rispetto alla quale è possibile effettuare chiamate normali. Ma in un linguaggio dinamico, in cui ogni chiamata deve utilizzare questi meccanismi, si tratta di un grave colpo di performance.

http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html

Così, per programmatori Java è essenzialmente inutile. Ho ragione? Da questo punto di vista, può essere considerato solo come un modo alternativo per l'API Core Reflection.

Answer 1

Precursore di Java 8 che fornisce supporto linguistico per MethodHandles. Sarai in grado di fare riferimento a un metodo direttamente e MethodHandles lo supporterà.

Che cosa si può fare con MethodHandles è metodi di curry, modificare i tipi di parametri e modificare il loro ordine.

Method Handles può gestire entrambi i metodi e campi.

Un altro trucco che MethodHandles fanno è utilizzare primitivi diretta (piuttosto che attraverso gli involucri)

MethodHandles può essere più veloce rispetto all'utilizzo di riflessione in quanto v'è un sostegno più diretto nella JVM per esempio possono essere inline. Usa la nuova istruzione invokedynamic.

Answer 2

java.lang.reflect.Method è relativamente lento e costoso in termini di memoria. Si suppone che i manici di metodo siano un modo "leggero" di passare i puntatori a funzioni che la JVM ha la possibilità di ottimizzare. A partire dal metodo JDK8, gli handle non sono ottimizzati in modo ottimale e probabilmente i lambda saranno inizialmente implementati in termini di classi (come le classi interne).

Answer 3

Pensa a MethodHandle come un modo moderno, più flessibile e più tipicamente di riflettere.

Attualmente è nelle prime fasi del suo ciclo di vita, ma nel tempo ha il potenziale per essere ottimizzato per diventare più veloce della riflessione - al punto che può diventare veloce come una normale chiamata di metodo.