MethodHandle - Che cos'è tutto questo?

Question

Sto studiando nuove caratteristiche del JDK 1.7 e riesco proprio non capisco cosa MethodHandle è progettato per? Comprendo invocazione (diretto) del metodo statico (e uso Core API Reflection che è semplice in questo caso). Capisco anche invocazione (diretta) del metodo virtuale (non statico, non definitivo) (e l'uso dei core API Reflection che richiede passare attraverso obj.getClass().getSuperclass() gerarchia di classe). Invocazione del metodo non virtuale può essere trattata come caso particolare della precedente.

Sì, lo consapevole del fatto che c'è un problema con sovraccarico. Se si vuole richiamare il metodo è necessario fornire la firma esatta. Non è possibile verificare la presenza di metodo di overload in modo semplice.

Ma, che cosa è MethodHandle circa? Reflection API permette di "sguardo sulle" parti interne degli oggetti senza alcun pre-assunzione (come implementato l'interfaccia). È possibile controllare l'oggetto per un certo scopo. Ma ciò che è MethodHandle è stato progettato troppo? Perché e quando dovrei usarlo?

UPDATE: sto leggendo ora questo http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html articolo. In base ad esso, l'obiettivo principale è quello di semplificare la vita per i linguaggi di scripting che corre in cima della JVM, e non per linguaggio Java 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, attraverso la promozione di linguaggi dinamici di prima classe cittadini JVM, lo dimostrerà.

Utilizzo di riflessione per richiamare i metodi funziona alla grande ... tranne che per alcuni problemi. oggetti metodo deve essere recuperati da un tipo specifico, e non possono essere creati in modo generale. <...>

... invocazione riflessa è molto più lento di invocazione diretta. Nel corso degli anni, la JVM ha ottenuto veramente bravo a fare riflessa veloce invocazione. JVM moderni in realtà generano un mucchio di codice dietro le quinte per evitare una gran parte dei vecchi JVM generali affrontati. Ma la semplice verità è che l'accesso riflessa attraverso qualsiasi numero di strati sarà sempre più lento di una chiamata diretta, in parte perché il completamente generified "invoke" metodo deve controllare e ricontrollare tipo di ricevitore, tipi di argomento, visibilità, e altri dettagli, ma anche perché argomenti devono essere tutti oggetti (così primitive ottenere oggetti riquadro) e devono essere forniti come un array per coprire tutte le possibili arietà (così argomenti ottengono array riquadro).

La differenza di prestazioni non può importa per una libreria fare un paio di telefonate riflesse, soprattutto se quelle chiamate sono per lo più per impostare dinamicamente una struttura statica in memoria contro il quale si può effettuare chiamate normali. Ma in un linguaggio dinamico, dove ogni chiamata deve utilizzare questi meccanismi, è un grave calo di prestazioni.

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

Quindi, per programmatori Java è sostanzialmente inutile. Ho ragione? Da questo punto di vista, può considerarsi come modo alternativo per Nucleo Reflection API.

Answer 1

Che cosa si può fare con MethodHandles è metodi di curry, cambiate le tipologie di parametri e cambiare il loro ordine.

Le maniglie metodo in grado di gestire entrambi i metodi e campi.

Un altro trucco che MethodHandles fare è utilizzare primitivo diretta (piuttosto che attraverso gli involucri)

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

Answer 2

java.lang.reflect.Method è relativamente lento e costoso in termini di memoria. maniglie Metodo dovrebbero essere un modo "leggero" di passare intorno puntatori a funzioni che la JVM ha la possibilità di ottimizzare. Al metodo maniglie JDK8 non sono che ben ottimizzato e lambda sono suscettibili di essere inizialmente attuate in termini di classi (classi interne sono).

Answer 3

Pensate MethodHandle come un modo più typesafe moderna, più flessibile di fare riflessione.

E 'attualmente nelle prime fasi del suo ciclo di vita - ma nel tempo ha il potenziale per essere ottimizzato per diventare mosto più velocemente di riflessione -. Al punto che può diventare veloce come una chiamata di metodo regolare