MethodHandle Classe

Definizione

[Android.Runtime.Register("java/lang/invoke/MethodHandle", ApiSince=26, DoNotGenerateAcw=true)]
public abstract class MethodHandle : Java.Lang.Object

[<Android.Runtime.Register("java/lang/invoke/MethodHandle", ApiSince=26, DoNotGenerateAcw=true)>]
type MethodHandle = class
    inherit Object

Ereditarietà

Object

JavaObject

Object

MethodHandle

Attributi

RegisterAttribute

Commenti

Un handle di metodo è un riferimento eseguibile diretto tipizzato a un metodo, un costruttore, un campo o un'operazione di basso livello simile, con trasformazioni facoltative di argomenti o valori restituiti. Queste trasformazioni sono piuttosto generali e includono modelli come conversione #asType, inserimento #bindTo, java.lang.invoke.MethodHandles#dropArguments e sostituzione java.lang.invoke.MethodHandles#filterArguments.

<gli handle di metodo h1>contents</h1> Vengono tipizzato dinamicamente e fortemente tipizzato in base al parametro e ai tipi restituiti. Non sono distinti in base al nome o alla classe di definizione dei relativi metodi sottostanti. È necessario richiamare un handle di metodo usando un descrittore di tipo simbolico che corrisponde al descrittore di tipo #type dell'handle del metodo.

Ogni handle di metodo segnala il descrittore di tipo tramite la #type type funzione di accesso. Questo descrittore di tipo è un java.lang.invoke.MethodType MethodType oggetto, la cui struttura è una serie di classi, una delle quali è il tipo restituito del metodo (o void.class se nessuna).

Il tipo di handle di un metodo controlla i tipi di chiamate che accetta e i tipi di trasformazioni applicabili.

Un handle di metodo contiene una coppia di metodi invoker speciali denominati #invokeExact invokeExact e #invoke invoke. Entrambi i metodi invoker forniscono l'accesso diretto al metodo, al costruttore, al campo o all'altra operazione sottostante dell'handle di metodo, come modificato dalle trasformazioni di argomenti e valori restituiti. Entrambi i chiamanti accettano chiamate che corrispondono esattamente al tipo di handle del metodo. Il invoker inesattivo normale accetta anche un intervallo di altri tipi di chiamata.

Gli handle di metodo non sono modificabili e non hanno uno stato visibile. Naturalmente, possono essere associati a metodi o dati sottostanti che presentano lo stato. Per quanto riguarda il modello di memoria Java, qualsiasi handle di metodo si comporta come se tutti i relativi campi (interni) siano variabili finali. Ciò significa che qualsiasi handle di metodo reso visibile all'applicazione sarà sempre completamente formato. Questo vale anche se l'handle del metodo viene pubblicato tramite una variabile condivisa in una gara di dati.

Gli handle di metodo non possono essere sottoclassati dall'utente. Le implementazioni possono (o meno) creare sottoclassi interne di MethodHandle cui possono essere visibili tramite l'operazione java.lang.Object#getClass Object.getClass . Il programmatore non deve trarre conclusioni su un handle di metodo dalla relativa classe specifica, in quanto la gerarchia della classe di handle del metodo (se presente) può cambiare di volta in volta o tra implementazioni di fornitori diversi.

<h1 Method handle compilation/h1 A Java method call expression naming or can invoke a method handle from Java source code.h1>Method handle compilation</h1> A Java method call expression naming invokeExact or invoke can invoke a method handle from Java source code. Dal punto di vista del codice sorgente, questi metodi possono accettare qualsiasi argomento e il relativo risultato può essere eseguito a qualsiasi tipo restituito. Questa operazione viene eseguita formalmente assegnando ai metodi Object invoker i tipi restituiti e gli argomenti di arità Object variabile, ma hanno una qualità aggiuntiva denominata <polimorfismo> della firma/<em> che connette questa libertà di chiamata direttamente allo stack di esecuzione JVM.

Come avviene normalmente con i metodi virtuali, le chiamate a livello di origine a invokeExact e invoke la compilazione in un'istruzione invokevirtual . In modo più insolito, il compilatore deve registrare i tipi di argomento effettivi e potrebbe non eseguire conversioni di chiamate al metodo sugli argomenti. Deve invece eseguirne il push nello stack in base ai propri tipi non convertiti. L'oggetto handle del metodo stesso viene inserito nello stack prima degli argomenti. Il compilatore chiama quindi l'handle del metodo con un descrittore di tipo simbolico che descrive l'argomento e i tipi restituiti.

Per rilasciare un descrittore di tipo simbolico completo, il compilatore deve anche determinare il tipo restituito. Questa operazione si basa su un cast sull'espressione di chiamata al metodo, se presente oppure Object se la chiamata è un'espressione oppure void se la chiamata è un'istruzione . Il cast può essere di un tipo primitivo (ma non void).

Come caso di angolo, a un argomento non sottoposto a null cast viene assegnato un descrittore di tipo simbolico di java.lang.Void. L'ambiguità con il tipo Void è innocua, poiché non sono presenti riferimenti di tipo Void ad eccezione del riferimento Null.

<h1>La<> prima volta che viene eseguita un'istruzione invokevirtual viene collegata, risolvendo simbolicamente i nomi nell'istruzione e verificando che la chiamata al metodo sia legale in modo statico. Questo vale per le chiamate a invokeExact e invoke. In questo caso, il descrittore di tipo simbolico generato dal compilatore viene controllato per individuare la sintassi corretta e i nomi in esso contenuti vengono risolti. Pertanto, un'istruzione invokevirtual che richiama un handle di metodo verrà sempre collegato, purché il descrittore di tipo simbolico sia sintatticamente ben formato e i tipi esistano.

Quando l'oggetto invokevirtual viene eseguito dopo il collegamento, il tipo di handle del metodo ricevente viene prima controllato dalla JVM per assicurarsi che corrisponda al descrittore di tipo simbolico. Se la corrispondenza del tipo ha esito negativo, significa che il metodo che il chiamante sta richiamando non è presente sul singolo handle del metodo richiamato.

Nel caso di invokeExact, il descrittore di tipo della chiamata (dopo aver risolto i nomi dei tipi simbolici) deve corrispondere esattamente al tipo di metodo dell'handle del metodo ricevente. Nel caso di testo normale, inexact invoke, il descrittore di tipo risolto deve essere un argomento valido per il metodo del #asType asType ricevitore. Pertanto, plain invoke è più permissivo di invokeExact.

Dopo la corrispondenza dei tipi, una chiamata a invokeExact richiama direttamente e immediatamente il metodo sottostante dell'handle del metodo (o un altro comportamento, come nel caso).

Una chiamata a plain invoke funziona come una chiamata a invokeExact, se il descrittore di tipo simbolico specificato dal chiamante corrisponde esattamente al tipo di handle del metodo. Se esiste una mancata corrispondenza del tipo, invoke tenta di modificare il tipo dell'handle del metodo ricevente, come se tramite una chiamata a #asType asType, per ottenere un handle M2di metodo richiamabile esattamente . Ciò consente una negoziazione più potente del tipo di metodo tra il chiamante e il chiamato.

(<em>Nota:/em< L'handle>M2 del metodo regolato non è osservabile direttamente e le implementazioni non sono pertanto necessarie per materializzarlo.

<h1>Controllo chiamate</h1> Nei programmi tipici, la corrispondenza dei tipi di handle del metodo in genere avrà esito positivo. Tuttavia, se una corrispondenza ha esito negativo, la JVM genererà un WrongMethodTypeExceptionoggetto , direttamente (nel caso di invokeExact) o indirettamente come se una chiamata non riuscita a asType (nel caso di invoke).

Pertanto, un tipo di metodo non corrispondente che potrebbe essere visualizzato come un errore di collegamento in un programma tipizzato staticamente può essere visualizzato come dinamico WrongMethodTypeException in un programma che usa handle di metodo.

Poiché i tipi di metodo contengono oggetti "attivi", Class la corrispondenza dei tipi di metodo prende in considerazione sia i nomi dei tipi che i caricatori di classi. Pertanto, anche se un handle M di metodo viene creato in un caricatore L1 di classi e usato in un altro L2, le chiamate handle del metodo sono indipendenti dai tipi, perché il descrittore di tipo simbolico del chiamante, come risolto in L2, viene confrontato con il descrittore di tipo simbolico del metodo chiamato originale, come risolto in L1. La risoluzione in L1 si verifica quando M viene creato e il relativo tipo viene assegnato, mentre la risoluzione in L2 si verifica quando l'istruzione invokevirtual è collegata.

Oltre al controllo dei descrittori di tipo, la capacità di un handle di metodo di chiamare il metodo sottostante non è limitata. Se un handle di metodo viene formato su un metodo non pubblico da una classe che ha accesso a tale metodo, l'handle risultante può essere utilizzato in qualsiasi posizione da qualsiasi chiamante che riceve un riferimento a tale metodo.

A differenza dell'API Reflection core, in cui l'accesso viene controllato ogni volta che viene richiamato un metodo riflettente, il controllo di accesso dell'handle del metodo viene eseguito quando viene creato l'handle del metodo. Nel caso di (vedere di seguito), il controllo di ldc accesso viene eseguito come parte del collegamento della voce del pool costante sottostante l'handle del metodo costante.

Pertanto, gli handle ai metodi non pubblici o ai metodi in classi non pubbliche devono essere generalmente mantenuti segreti. Non devono essere passati a codice non attendibile, a meno che l'uso del codice non attendibile non sia innocuo.

<h1>Metodo handle creation</h1> Java codice può creare un handle di metodo che accede direttamente a qualsiasi metodo, costruttore o campo accessibile a tale codice. Questa operazione viene eseguita tramite un'API basata su funzionalità riflettente denominata java.lang.invoke.MethodHandles.Lookup MethodHandles.Lookup Ad esempio, un handle di metodo statico può essere ottenuto da java.lang.invoke.MethodHandles.Lookup#findStatic Lookup.findStatic. Sono disponibili anche metodi di conversione da oggetti DELL'API Reflection core, ad esempio java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflect.

Analogamente a classi e stringhe, gli handle di metodo che corrispondono a campi, metodi e costruttori accessibili possono anche essere rappresentati direttamente nel pool costante di un file di classe come costanti da caricare da ldc bytecode. Un nuovo tipo di voce del pool costante, CONSTANT_MethodHandle, fa riferimento direttamente a una voce del pool costante , o CONSTANT_Methodref associataCONSTANT_InterfaceMethodrefCONSTANT_Fieldref. Per informazioni dettagliate sulle costanti di handle dei metodi, vedere le sezioni 4.4.8 e 5.4.3.5 della specifica della macchina virtuale di Java.

Gli handle di metodo prodotti da ricerche o carichi costanti da metodi o costruttori con il bit del modificatore di arità variabile (0x0080) hanno un'arità variabile corrispondente, come se fossero stati definiti con l'aiuto di #asVarargsCollector asVarargsCollector.

Un riferimento al metodo può fare riferimento a un metodo statico o non statico. Nel caso non statico, il tipo di handle del metodo include un argomento ricevitore esplicito, anteporto a qualsiasi altro argomento. Nel tipo dell'handle del metodo, l'argomento ricevitore iniziale viene tipizzato in base alla classe in cui è stato inizialmente richiesto il metodo. Ad esempio, se un handle di metodo non statico viene ottenuto tramite ldc, il tipo del ricevitore è la classe denominata nella voce del pool costante.

Le costanti dell'handle del metodo sono soggette agli stessi controlli di accesso in fase di collegamento alle istruzioni di bytecode corrispondenti e l'istruzione ldc genererà errori di collegamento corrispondenti se i comportamenti bytecode genererebbero tali errori.

Di conseguenza, l'accesso ai membri protetti è limitato solo ai ricevitori della classe di accesso o a una delle relative sottoclassi e la classe di accesso deve a sua volta essere una sottoclasse (o un pacchetto di pari livello) della classe di definizione del membro protetto. Se un riferimento al metodo fa riferimento a un metodo o a un campo non statico protetto di una classe all'esterno del pacchetto corrente, l'argomento ricevitore verrà ristretto al tipo della classe di accesso.

Quando viene richiamato un handle di metodo per un metodo virtuale, il metodo viene sempre cercato nel ricevitore, ovvero il primo argomento.

È anche possibile creare un handle di metodo non virtuale per un'implementazione specifica del metodo virtuale. Queste operazioni non eseguono ricerche virtuali in base al tipo di ricevitore. Tale handle di metodo simula l'effetto di un'istruzione invokespecial allo stesso metodo.

<h1>Esempi< di utilizzo/h1> Ecco alcuni esempi di utilizzo: <blockquote>

{@code
            Object x, y; String s; int i;
            MethodType mt; MethodHandle mh;
            MethodHandles.Lookup lookup = MethodHandles.lookup();
            // mt is (char,char)String
            mt = MethodType.methodType(String.class, char.class, char.class);
            mh = lookup.findVirtual(String.class, "replace", mt);
            s = (String) mh.invokeExact("daddy",'d','n');
            // invokeExact(Ljava/lang/String;CC)Ljava/lang/String;
            assertEquals(s, "nanny");
            // weakly typed invocation (using MHs.invoke)
            s = (String) mh.invokeWithArguments("sappy", 'p', 'v');
            assertEquals(s, "savvy");
            // mt is (Object[])List
            mt = MethodType.methodType(java.util.List.class, Object[].class);
            mh = lookup.findStatic(java.util.Arrays.class, "asList", mt);
            assert(mh.isVarargsCollector());
            x = mh.invoke("one", "two");
            // invoke(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList("one","two"));
            // mt is (Object,Object,Object)Object
            mt = MethodType.genericMethodType(3);
            mh = mh.asType(mt);
            x = mh.invokeExact((Object)1, (Object)2, (Object)3);
            // invokeExact(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList(1,2,3));
            // mt is ()int
            mt = MethodType.methodType(int.class);
            mh = lookup.findVirtual(java.util.List.class, "size", mt);
            i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
            // invokeExact(Ljava/util/List;)I
            assert(i == 3);
            mt = MethodType.methodType(void.class, String.class);
            mh = lookup.findVirtual(java.io.PrintStream.class, "println", mt);
            mh.invokeExact(System.out, "Hello, world.");
            // invokeExact(Ljava/io/PrintStream;Ljava/lang/String;)V
            }

</blockquote> Ogni chiamata precedente a invokeExact o plain invoke genera una singola istruzione invokevirtual con il descrittore di tipo simbolico indicato nel commento seguente. In questi esempi si presuppone che il metodo assertEquals helper sia un metodo che chiama java.util.Objects#equals(Object,Object) Objects.equals gli argomenti e asserisce che il risultato è true.

<h1>Exceptions</h1> I metodi invokeExact e invoke vengono dichiarati per generare java.lang.Throwable Throwable, vale a dire che non esiste alcuna restrizione statica su ciò che un handle di metodo può generare. Poiché la JVM non distingue tra le eccezioni controllate e non controllate (ad eccezione della relativa classe, naturalmente), non vi è alcun effetto particolare sulla forma bytecode dall'applicazione di eccezioni controllate alle chiamate del metodo. In Java codice sorgente, tuttavia, i metodi che eseguono chiamate di handle dei metodi devono generare Throwablein modo esplicito , oppure devono intercettare tutti gli elementi generati localmente, rigenerando solo quelli legali nel contesto e eseguendo il wrapping di quelli illegali.

<h1>"sigpoly">Polymorphism della firma/h1< Il comportamento insolito di compilazione e collegamento di > e plain invokeExact è fatto riferimento al termine invokepolimorfismo<> della firma em</em>. Come definito nella specifica del linguaggio di Java, un metodo polimorfico di firma è uno che può operare con una vasta gamma di firme di chiamata e tipi restituiti.

Nel codice sorgente, una chiamata a un metodo polimorfico della firma verrà compilata, indipendentemente dal descrittore di tipo simbolico richiesto. Come di consueto, il compilatore Java genera un'istruzione invokevirtual con il descrittore di tipo simbolico specificato sul metodo denominato. La parte insolita è che il descrittore di tipo simbolico è derivato dall'argomento effettivo e dai tipi restituiti, non dalla dichiarazione del metodo.

Quando la JVM elabora bytecode contenente chiamate polimorfiche di firma, questa chiamata verrà con esito positivo, indipendentemente dal descrittore di tipo simbolico. Per mantenere la sicurezza dei tipi, la JVM proteggerà tali chiamate con controlli di tipo dinamico appropriati, come descritto altrove.

I generatori di bytecode, incluso il back-end del compilatore, sono necessari per generare descrittori di tipi simbolici non trasformati per questi metodi. Gli strumenti che determinano il collegamento simbolico sono necessari per accettare tali descrittori non trasformati, senza segnalare errori di collegamento.

<h1>Interoperabilità tra handle di metodo e API< Reflection core/h1> Usando i metodi factory nell'API java.lang.invoke.MethodHandles.Lookup Lookup , qualsiasi membro di classe rappresentato da un oggetto API Reflection core può essere convertito in un handle di metodo equivalente a livello comportamentale. Ad esempio, un oggetto riflettente java.lang.reflect.Method Method può essere convertito in un handle di metodo usando java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflect. Gli handle del metodo risultante forniscono in genere un accesso più diretto ed efficiente ai membri della classe sottostante.

Come caso speciale, quando l'API Reflection core viene usata per visualizzare i metodi invokeExact polimorfici della firma o normale invoke in questa classe, vengono visualizzati come normali metodi non polimorfici. L'aspetto riflettente, come visualizzato da java.lang.Class#getDeclaredMethod Class.getDeclaredMethod, non è influenzato dal relativo stato speciale in questa API. Ad esempio, java.lang.reflect.Method#getModifiers Method.getModifiers in questo caso e i bit del modificatore necessari per qualsiasi metodo dichiarato in modo analogo, inclusi in questo caso native e varargs bit.

Come per qualsiasi metodo riflesso, questi metodi (se riflesse) possono essere richiamati tramite java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke. Tuttavia, tali chiamate riflettenti non comportano chiamate all'handle del metodo. Tale chiamata, se è stato passato l'argomento obbligatorio (un singolo, di tipo Object[]), ignorerà l'argomento e genererà un'eccezione UnsupportedOperationException.

Poiché invokevirtual le istruzioni possono richiamare in modo nativo handle di metodo in qualsiasi descrittore di tipo simbolico, questa visualizzazione riflettente è in conflitto con la normale presentazione di questi metodi tramite bytecode. Pertanto, questi due metodi nativi, se visualizzati in modo riflessivo da Class.getDeclaredMethod, possono essere considerati solo segnaposto.

Per ottenere un metodo invoker per un descrittore di tipo specifico, usare java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvokero java.lang.invoke.MethodHandles#invoker MethodHandles.invoker. L'API java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual è anche in grado di restituire un handle di metodo da chiamare invokeExact o normale invokeper qualsiasi descrittore di tipo specificato.

<H1>Interoperabilità tra handle di metodo e Java handle di metodo generics</h1> Un handle di metodo può essere ottenuto in un metodo, un costruttore o un campo dichiarato con Java tipi generici. Come per l'API Reflection core, il tipo di handle del metodo verrà costruito dalla cancellazione del tipo a livello di origine. Quando viene richiamato un handle di metodo, i tipi dei relativi argomenti o il tipo cast del valore restituito possono essere tipi o istanze di tipo generici. In questo caso, il compilatore sostituirà tali tipi in base alle relative eliminazioni quando costruisce il descrittore di tipo simbolico per l'istruzione invokevirtual .

Gli handle di metodo non rappresentano i tipi simili a funzione in termini di tipi Java parametrizzati (generici), perché esistono tre mancate corrispondenze tra tipi simili a funzioni e tipi di Java con parametri. <Ul><li>Method types range over all possible arities, from no arguments to up the maximum number of allowed arguments. I generics non sono variadic e quindi non possono rappresentare questo.<I tipi di metodo /li><>possono specificare argomenti di tipi primitivi, che Java tipi generici non possono essere compresi nell'intervallo.<Le funzioni di ordine superiore /li><>su handle di metodo (combinatori) sono spesso generiche in un'ampia gamma di tipi di funzione, inclusi quelli di più arità. È impossibile rappresentare tale genericità con un parametro di tipo Java.</li></ul>

<h1>"maxarity">Arity limits</h1> La JVM impone a tutti i metodi e ai costruttori di qualsiasi tipo un limite assoluto di 255 argomenti in pila. Questo limite può apparire più restrittivo in determinati casi: <ul><li>A long o double conteggi degli argomenti (ai fini dei limiti di arità) come due slot di argomento. <li>Un metodo non statico utilizza un argomento aggiuntivo per l'oggetto su cui viene chiamato il metodo . <li>Un costruttore utilizza un argomento aggiuntivo per l'oggetto che viene costruito. <li>Since a method handle' il metodo s invoke (o altro metodo polimorfico della firma) non virtuale, utilizza un argomento aggiuntivo per l'handle del metodo stesso, oltre a qualsiasi oggetto ricevitore non virtuale. </ul> Questi limiti implicano che non è possibile creare determinati handle di metodo, esclusivamente a causa del limite JVM per gli argomenti in pila. Ad esempio, se un metodo JVM statico accetta esattamente 255 argomenti, non è possibile creare un handle di metodo per tale metodo. I tentativi di creare handle di metodo con tipi di metodo impossibili portano a un oggetto IllegalArgumentException. In particolare, un handle di metodo' il tipo s non deve avere un'arità del massimo esatto 255.

per java.lang.invoke.MethodHandle.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dalla e usati in base ai termini descritti in Creative License 2.5 Attribution License.