MethodHandle Classe

Definizione

Spazio dei nomi:

Java.Lang.Invoke

Assembly:

Mono.Android.dll

Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.

[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

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 la conversione #asType, l'inserimento #bindTo, java.lang.invoke.MethodHandles#dropArguments e la sostituzione java.lang.invoke.MethodHandles#filterArguments.

<gli handle di metodo h1>contents</h1> Method sono tipizzato in modo dinamico e fortemente tipizzato in base al parametro e ai tipi restituiti. Non sono distinti in base al nome o alla classe di definizione dei metodi sottostanti. È necessario richiamare un handle di metodo usando un descrittore di tipo simbolico che corrisponde al descrittore di tipo #type 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 un handle di metodo controlla i tipi di chiamate accettati 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 ad altre operazioni sottostanti dell'handle del metodo, come modificato dalle trasformazioni di argomenti e valori restituiti. Entrambi i invoker accettano chiamate che corrispondono esattamente al tipo di handle del metodo. Il invoker inesact 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 verrà sempre completamente formato. Ciò vale anche se l'handle del metodo viene pubblicato tramite una variabile condivisa in una gara di dati.

Gli handle del 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, perché la gerarchia della classe gestita dal metodo (se presente) può cambiare di tanto in tanto o tra implementazioni di fornitori diversi.

<h1>Handle di compilazione</h1> Un nome di espressione di chiamata invokeExact del metodo Java o invoke può richiamare un handle di metodo dal codice sorgente Java. 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 formalmente eseguita assegnando ai metodi Object invoker i tipi restituiti e gli argomenti di arità Object variabile, ma hanno una qualità aggiuntiva denominata <>polimorfismo</em> della firma 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 invertiti. 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 eseguire un descrittore di tipo simbolico completo, il compilatore deve anche determinare il tipo restituito. 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 a un tipo primitivo (ma non voida ).

Come caso dell'angolo, a un argomento non sottoposto null acast 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>Handle di chiamata< al metodo/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. Ciò 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 connessa, purché il descrittore di tipo simbolico sia sintatticamente ben formato e che i tipi esistano.

Quando l'oggetto invokevirtual viene eseguito dopo il collegamento, il tipo dell'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 richiamato dal chiamante non è presente nel singolo handle del metodo richiamato.

Nel caso di , il descrittore di invokeExacttipo 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. Di conseguenza, la semplicità invoke è più permissiva 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 potrebbe essere).

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 è presente 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 M2del 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 modificato non è osservabile direttamente e le implementazioni non sono quindi necessarie per materializzarlo.

<h1>Controllo< chiamate/h1> Nei programmi tipici, la corrispondenza del tipo di handle del metodo ha in genere 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 a non fosse riuscita a asType (nel caso di invoke).

Di conseguenza, un tipo di metodo non corrispondente che potrebbe essere visualizzato come un errore di collegamento in un programma tipizzato in modo statico 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 classe. Pertanto, anche se un handle M di metodo viene creato in un caricatore L1 di classi e usato in un altro L2, le chiamate di 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 funzionalità di un handle di metodo per chiamare il metodo sottostante non è limitata. Se un handle di metodo viene formato in un metodo non pubblico da una classe che ha accesso a tale metodo, l'handle risultante può essere usato in qualsiasi posizione da qualsiasi chiamante che riceve un riferimento.

A differenza dell'API Reflection di base, in cui l'accesso viene controllato ogni volta che viene richiamato un metodo riflettente, la gestione dei metodi viene eseguita 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 nelle classi non pubbliche devono in genere essere 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 code can create a method handle that directly accesses any method, constructor, or field that is accessible to that code. 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 , CONSTANT_InterfaceMethodrefo CONSTANT_Fieldref associataCONSTANT_Methodref. Per informazioni dettagliate sulle costanti dell'handle dei metodi, vedere le sezioni 4.4.8 e 5.4.3.5 della specifica della macchina virtuale 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 una 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, prependato prima di qualsiasi altro argomento. Nel tipo di handle del metodo l'argomento ricevitore iniziale viene digitato in base alla classe in cui è stato richiesto inizialmente 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 di gestione dei metodi sono soggette allo stesso accesso al tempo di collegamento controllano le istruzioni di bytecode corrispondenti e l'istruzione ldc genererà errori di collegamento corrispondenti se i comportamenti bytecode genererebbero tali errori.

In questo modo, 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 non statico protetto o a un campo di una classe all'esterno del pacchetto corrente, l'argomento ricevitore verrà limitato al tipo della classe di accesso.

Quando viene richiamato un handle di metodo a 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. Questi 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 invoke normale genera un'unica istruzione invokevirtual con il descrittore> di tipo simbolico indicato nel commento seguente. In questi esempi si presuppone che il metodo helper sia un metodo assertEquals 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, ovvero che non esiste alcuna restrizione statica su quale handle di metodo può generare. Poiché la JVM non distingue tra le eccezioni controllate e deselezionate (diversamente dalla classe, naturalmente), non vi è alcun effetto particolare sulla forma bytecode dalle eccezioni controllate per gestire le chiamate al metodo. Tuttavia, nel codice sorgente Java, i metodi che eseguono la gestione dei metodi devono generare in modo esplicito Throwable, oppure devono rilevare tutti gli generabili in locale, ritentando solo quelli legali nel contesto e i wrapping che sono illegali.

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

Nel codice sorgente, una chiamata a un metodo polimorfico 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, verrà collegato correttamente qualsiasi chiamata, indipendentemente dal descrittore di tipo simbolico. Per mantenere la sicurezza dei tipi, la JVM sorveglia tali chiamate con controlli di tipo dinamici appropriati, come descritto altrove.

I generatori di bytecode, inclusi il back-end del compilatore, sono necessari per generare descrittori di tipo simbolico nontransformed per questi metodi. Gli strumenti che determinano il collegamento simbolico sono necessari per accettare tali descrittori non tradotti, senza segnalare errori di collegamento.

<h1>Interoperabilità tra handle di metodi e l'API Reflection core/h1> Usando i metodi factory nell'APIjava.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 in modo 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. I metodi risultanti gestiscono in genere l'accesso più diretto ed efficiente ai membri della classe sottostante.

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

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

Poiché invokevirtual le istruzioni possono richiamare in modo nativo i handle del metodo in qualsiasi descrittore di tipo simbolico, questa vista riflettente è in conflitto con la normale presentazione di questi metodi tramite bytecodes. Pertanto, questi due metodi nativi, quando 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 per chiamare invokeExact o invokenormale , per qualsiasi descrittore di tipo specificato.

<h1>Interoperabilità tra handle di metodi e handle di metodo Java generics/h1> È possibile ottenere un handle di metodo, costruttore o campo dichiarato con tipi generici< Java. Come per l'API Reflection core, il tipo dell'handle del metodo verrà costruito dalla cancellazione del tipo di origine. Quando viene richiamato un handle di metodo, i tipi degli argomenti o il tipo di cast del valore restituito possono essere tipi generici o istanze di tipo. 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 dei metodi non rappresentano i tipi simili alle funzioni in termini di tipi Java con parametri (generici), perché sono presenti tre mancate corrispondenze tra tipi simili a funzioni e tipi Java con parametri. <ul><li>Tipi di metodo sono compresi in tutte le possibili arità, da nessun argomento fino al numero massimo di argomenti consentiti. I generics non sono variadic e quindi non possono rappresentare questo.<I tipi di metodo /li><>li possono specificare argomenti di tipi primitivi, che i tipi generici Java non possono variare.<Le funzioni di ordine superiore /li><>su handle di metodi (combinatori) spesso sono generiche in un'ampia gamma di tipi di funzioni, inclusi quelli di più arities. Non è possibile 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 arity) come due slot di argomento. <li>Un metodo non statico usa un argomento aggiuntivo per l'oggetto in cui viene chiamato il metodo. <li>Un costruttore usa un argomento aggiuntivo per l'oggetto che viene costruito. <li>Poiché un handle di metodo’ il metodo s invoke (o altro metodo polimorfico di firma) è non virtuale, usa 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, solo a causa del limite JVM sugli argomenti in pila. Ad esempio, se un metodo JVM statico accetta esattamente 255 argomenti, non è possibile creare un handle di metodo per esso. I tentativi di creazione di handle dei metodi con tipi di metodo impossibili portano a un IllegalArgumentExceptionoggetto . In particolare, un handle di metodo’ il tipo s non deve avere un'arità del massimo esatto 255.

Documentazione Java per java.lang.invoke.MethodHandle.

Le parti di questa pagina sono modifiche in base al lavoro creato e condiviso dal Android Open Source e usato in base ai termini descritti nella .

Costruttori

MethodHandle(IntPtr, JniHandleOwnership)

Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.

Proprietà

Class	Restituisce la classe di runtime di questo Objectoggetto . (Ereditato da Object)
Handle	Handle per l'istanza di Android sottostante. (Ereditato da Object)
IsVarargsCollector	Determina se questo handle di metodo supporta #asVarargsCollector chiamate di arità delle variabili.
JniIdentityHashCode	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
JniPeerMembers	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.
PeerReference	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
ThresholdClass	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.
ThresholdType	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.

Metodi

AsCollector(Class, Int32)	Crea un <handle di metodo em>array-collect</em> , che accetta un determinato numero di argomenti posizionali finali e li raccoglie in un argomento di matrice.
AsCollector(Int32, Class, Int32)	Crea un <handle di metodo em>array-collect</em> , che accetta un determinato numero di argomenti posizionali a partire da una determinata posizione e li raccoglie in un argomento di matrice.
AsFixedArity()	Crea un <handle di metodo em>fixed arity</em> che altrimenti equivale all'handle del metodo corrente.
AsSpreader(Class, Int32)	Crea un <handle di metodo em>array-spread</em> , che accetta un argomento matrice finale e distribuisce i relativi elementi come argomenti posizionali.
AsSpreader(Int32, Class, Int32)	Crea un <handle di metodo em>array-spread</em> , che accetta un argomento matrice in una determinata posizione e distribuisce i relativi elementi come argomenti posizionali al posto della matrice.
AsType(MethodType)	Produce un handle del metodo adapter che adatta il tipo dell'handle del metodo corrente a un nuovo tipo.
AsVarargsCollector(Class)	Crea un <adattatore em>variable arity</em> in grado di accettare un numero qualsiasi di argomenti posizionali finali e raccoglierli in un argomento di matrice.
BindTo(Object)	Associa un valore x al primo argomento di un handle di metodo, senza richiamarlo.
Clone()	Crea e restituisce una copia di questo oggetto. (Ereditato da Object)
Dispose()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
Dispose(Boolean)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
Equals(Object)	Indica se un altro oggetto è "uguale a" questo. (Ereditato da Object)
GetHashCode()	Restituisce un valore del codice hash per l'oggetto. (Ereditato da Object)
Invoke(Object[])	Richiama l'handle del metodo, consentendo qualsiasi descrittore di tipo chiamante e facoltativamente eseguendo conversioni su argomenti e valori restituiti.
InvokeExact(Object[])	Richiama l'handle del metodo, consentendo qualsiasi descrittore di tipo chiamante, ma richiedendo una corrispondenza esatta del tipo.
InvokeWithArguments(IList<Object>)	Esegue una chiamata di arità variabile, passando gli argomenti nella matrice specificata all'handle del metodo, come se tramite un'eccezione #invoke invoke da un sito di chiamata che menzioni solo il tipo Objecte la cui arità è la lunghezza della matrice di argomenti.
InvokeWithArguments(Object[])	Esegue una chiamata di arità variabile, passando gli argomenti nell'elenco specificato all'handle del metodo, come se tramite un'eccezione #invoke invoke da un sito di chiamata che menzioni solo il tipo Objecte la cui arità è la lunghezza dell'elenco di argomenti.
JavaFinalize()	Chiamato dal Garbage Collector su un oggetto quando Garbage Collection determina che non sono presenti altri riferimenti all'oggetto . (Ereditato da Object)
Notify()	Riattiva un singolo thread in attesa del monitor dell'oggetto. (Ereditato da Object)
NotifyAll()	Riattiva tutti i thread in attesa del monitoraggio di questo oggetto. (Ereditato da Object)
SetHandle(IntPtr, JniHandleOwnership)	Imposta la proprietà Handle. (Ereditato da Object)
ToArray<T>()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
ToString()	Restituisce una rappresentazione in formato stringa dell'oggetto. (Ereditato da Object)
Type()	Segnala il tipo di handle di questo metodo.
UnregisterFromRuntime()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
Wait()	Fa sì che il thread corrente attenda finché non viene risvegliato, in genere eseguendo <una>notifica</em> o <em>interrotto</em>. (Ereditato da Object)
Wait(Int64)	Fa sì che il thread corrente attenda finché non viene risvegliato, in genere eseguendo <una notifica</>em> o <em>interrotto</em> o fino a quando non è trascorsa una certa quantità di tempo reale. (Ereditato da Object)
Wait(Int64, Int32)	Fa sì che il thread corrente attenda finché non viene risvegliato, in genere eseguendo <una notifica</>em> o <em>interrotto</em> o fino a quando non è trascorsa una certa quantità di tempo reale. (Ereditato da Object)
WithVarargs(Boolean)	Adatta questo handle di metodo in modo che sia #asVarargsCollector'arità variabile se il flag booleano è true, altrimenti #asFixedArity arità fissa.

Implementazioni dell'interfaccia esplicita

IJavaPeerable.Disposed()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.DisposeUnlessReferenced()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.Finalized()	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.JniManagedPeerState	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.SetJniIdentityHashCode(Int32)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)
IJavaPeerable.SetPeerReference(JniObjectReference)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti. (Ereditato da Object)

Metodi di estensione

JavaCast<TResult>(IJavaObject)	Esegue una conversione del tipo verificato dal runtime Android.
JavaCast<TResult>(IJavaObject)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.
GetJniTypeName(IJavaPeerable)	Un handle di metodo è un riferimento diretto eseguibile a un metodo, un costruttore, un campo o un'operazione simile a basso livello, con trasformazioni facoltative di argomenti o valori restituiti.