MethodHandles.Lookup Classe

Definizione

Spazio dei nomi:

Java.Lang.Invoke

Assembly:

Mono.Android.dll

Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso.

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

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

Ereditarietà

Object

Object

MethodHandles.Lookup

Attributi

RegisterAttribute

Commenti

Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. Gli handle di metodo non eseguono controlli di accesso quando vengono chiamati, ma piuttosto quando vengono creati. Pertanto, la gestione dei metodi deve essere applicata quando viene creato un handle di metodo. La classe chiamante in base alla quale vengono applicate tali restrizioni è nota come classe di ricerca #lookupClass.

Una classe di ricerca che deve creare handle di metodo chiamerà #lookup MethodHandles.lookup per creare una factory per se stessa. Quando viene creato l'oggetto Lookup factory, l'identità della classe di ricerca viene determinata e archiviata in modo sicuro nell'oggetto Lookup . La classe di ricerca (o i relativi delegati) può quindi usare metodi factory nell'oggetto per creare handle di metodo per i membri controllati dall'accesso Lookup . Sono inclusi tutti i metodi, i costruttori e i campi consentiti per la classe di ricerca, anche quelli privati.

<h1>"lookups">Lookup Factory Methods</h1> I metodi factory di un Lookup oggetto corrispondono a tutti i casi d'uso principali per metodi, costruttori e campi. Ogni handle di metodo creato da un metodo factory è l'equivalente funzionale di un particolare <comportamento< di bytecode em>/em>. I comportamenti bytecode sono descritti nella sezione 5.4.3.5 della specifica della macchina virtuale Java. Ecco un riepilogo della corrispondenza tra questi metodi factory e il comportamento gestito dal metodo risultante: <table border=1 cellpadding=5 summary="lookup method behaviors"><tr><th>"equiv">lookup expression</th<>>member</th th<>>bytecode behavior</th></tr<>><td>java.lang.invoke.MethodHandles.Lookup#findGetter lookup.findGetter(C.class,"f",FT.class)</td><td/td/td>FT f;<><>(T) this.f;<><><tr><td>java.lang.invoke.MethodHandles.Lookup#findStaticGetter lookup.findStaticGetter(C.class,"f",FT.class)</td><td>static<br><FT f;/td td>><<(T) C.f;/td></tr><td></td>java.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class)< td><FT f;<>/td td<this.f = x;>></<>tr td></tr><td/td<>tdjava.lang.invoke.MethodHandles.Lookup#findStaticSetter lookup.findStaticSetter(C.class,"f",FT.class)<>><static br><FT f;/td td><C.f = arg;/td<><>/tr tr><><td><java.lang.invoke.MethodHandles.Lookup#findVirtual lookup.findVirtual(C.class,"m",MT)/td td>><T m(A*);</td><td>(T) this.m(arg*);</td/tr><td<>><>java.lang.invoke.MethodHandles.Lookup#findStatic lookup.findStatic(C.class,"m",MT)</td<>td>static<brT m(A*);></td td(T) C.m(arg*);>><</><tr tr><><td/td><java.lang.invoke.MethodHandles.Lookup#findSpecial lookup.findSpecial(C.class,"m",MT,this.class)/td<>tdT m(A*);></td><<>(T) super.m(arg*);></tr tr><><td><java.lang.invoke.MethodHandles.Lookup#findConstructor lookup.findConstructor(C.class,MT)/td td><<>C(A*);/td td>><<new C(arg*);/td></tr><<>td/tdjava.lang.invoke.MethodHandles.Lookup#unreflectGetter lookup.unreflectGetter(aField)<> td<>>(static)?<br><FT f;/td><td><(FT) aField.get(thisOrNull);/td></tr tr><><td/tdjava.lang.invoke.MethodHandles.Lookup#unreflectSetter lookup.unreflectSetter(aField)>< td><>(static)?<br><FT f;/td><td><aField.set(thisOrNull, arg);/td></tr tr><><td/tdjava.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)>< td><>(static)?<br>T m(A*);</td><td>(T) aMethod.invoke(thisOrNull, arg*);</td></tr tr>><<td/td>java.lang.invoke.MethodHandles.Lookup#unreflectConstructor lookup.unreflectConstructor(aConstructor)< td><C(A*);<>/td td>(C) aConstructor.newInstance(arg*);<></td></tr td></tr><td><java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)/td td<>>(static)?<br>T m(A*);</td><td/td><(T) aMethod.invoke(thisOrNull, arg*);<>/tr></table>

In questo caso, il tipo C è la classe o l'interfaccia in cui viene eseguita la ricerca di un membro, documentato come parametro denominato refc nei metodi di ricerca. Il tipo di metodo è composto dal tipo MTT restituito e dalla sequenza di tipi A*di argomento . Il costruttore ha anche una sequenza di tipi A* di argomento e viene considerato come restituire l'oggetto appena creato di tipo C. Sia MT che il tipo di FT campo sono documentati come parametro denominato type. Il parametro this formale è l'acronimo del self-reference di tipo C; se è presente, è sempre l'argomento iniziale per la chiamata dell'handle del metodo. Nel caso di alcuni protected membri, this potrebbe essere limitato nel tipo alla classe di ricerca. Vedere di seguito. Il nome arg è l'acronimo di tutti gli altri argomenti handle del metodo. Negli esempi di codice per l'API Reflection core il nome thisOrNull è un riferimento Null se il metodo o il campo a cui si accede è statico e this in caso contrario. I nomi aMethod, aFielde aConstructor sono corrispondenti agli oggetti riflettenti corrispondenti ai membri specificati.

Nei casi in cui il membro specificato è di arity variabile (ad esempio, un metodo o un costruttore), l'handle del metodo restituito sarà anche della variabile MethodHandle#asVarargsCollector. In tutti gli altri casi, l'handle del metodo restituito sarà di arità fissa. <p style="font-size:smaller;"><em>Discussion:</em> L'equivalenza tra handle del metodo looked-up e membri della classe sottostanti e comportamenti bytecode può essere suddiviso in alcuni modi: <ul style="font-size:smaller;"><li>Se C non è accessibile simbolicamente dal caricatore della classe di ricerca, la ricerca può comunque avere esito positivo, anche se non è presente alcuna espressione Java equivalente o costante bytecoded. <li>Analogamente, se T o MT non è simbolicamente accessibile dal caricatore della classe di ricerca, la ricerca può comunque avere esito positivo. Ad esempio, le ricerche per MethodHandle.invokeExact e MethodHandle.invoke avranno sempre esito positivo, indipendentemente dal tipo richiesto. <li>Se è installato un responsabile della sicurezza, può impedire la ricerca in vari motivi (vedere di seguito). Al contrario, l'istruzione ldc su una CONSTANT_MethodHandle costante non è soggetta ai controlli di gestione della sicurezza. <li>Se il metodo looked-up ha una grande arità, la creazione dell'handle del metodo potrebbe non riuscire, a causa del tipo di handle del metodo con troppi parametri. </ul>

<h1>"access">Controllo di accesso/h1> I< controlli di accesso vengono applicati nei metodi factory di , quando viene creato un handle di Lookupmetodo. Questa è una differenza fondamentale rispetto all'API Reflection core, perché java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke esegue il controllo di accesso su ogni chiamante, in ogni chiamata.

Tutti i controlli di accesso iniziano da un Lookup oggetto , che confronta la classe di ricerca registrata con tutte le richieste per creare handle di metodo. È possibile usare un singolo Lookup oggetto per creare un numero qualsiasi di handle di metodo con controllo di accesso, tutti controllati in base a una singola classe di ricerca.

Un Lookup oggetto può essere condiviso con altro codice attendibile, ad esempio un protocollo metaoggetto. Un oggetto condiviso Lookup delega la funzionalità di creazione di handle di metodo sui membri privati della classe di ricerca. Anche se il codice con privilegi usa l'oggetto Lookup , il controllo di accesso è limitato ai privilegi della classe di ricerca originale.

Una ricerca può avere esito negativo, perché la classe contenitore non è accessibile alla classe di ricerca o perché il membro della classe desiderato è mancante o perché il membro della classe desiderato non è accessibile alla classe di ricerca o perché l'oggetto di ricerca non è sufficientemente attendibile per accedere al membro. In uno di questi casi, verrà generata una classe ReflectiveOperationException dal tentativo di ricerca. La classe esatta sarà una delle seguenti: ul>li NoSuchMethodException — se viene richiesto un metodo ma non esiste <li>NoSuchFieldException — se viene richiesto un campo ma non esiste <li>IllegalAccessException — se il membro esiste ma un controllo di accesso non riesce </ul><<>

In generale, le condizioni in cui un handle di metodo può essere cercato per un metodo M non sono più restrittive delle condizioni in cui la classe di ricerca potrebbe avere compilato, verificato e risolto una chiamata a M. Se la JVM genera eccezioni come NoSuchMethodError, la ricerca di un handle di metodo genererà in genere un'eccezione controllata corrispondente, ad esempio NoSuchMethodException. E l'effetto di richiamare l'handle del metodo risultante dalla ricerca è esattamente equivalente all'esecuzione della chiamata compilata, verificata e risolta a M. Lo stesso punto è vero di campi e costruttori. <p style="font-size:smaller;"><em>Discussione:</em> Controlli di accesso si applicano solo a metodi denominati e riflessi, costruttori e campi. Altri metodi di creazione dell'handle di metodo, ad esempio MethodHandle#asType MethodHandle.asType, non richiedono alcun controllo di accesso e vengono usati indipendentemente da qualsiasi Lookup oggetto.

Se il membro desiderato è protected, si applicano le normali regole JVM, incluso il requisito che la classe di ricerca deve trovarsi nello stesso pacchetto del membro desiderato oppure deve ereditare tale membro. Vedere La specifica della macchina virtuale Java, le sezioni 4.9.2, 5.4.3.5 e 6.4. Inoltre, se il membro desiderato è un campo o un metodo non statico in un pacchetto diverso, l'handle del metodo risultante può essere applicato solo agli oggetti della classe di ricerca o a una delle relative sottoclassi. Questo requisito viene applicato restringendo il tipo del parametro iniziale this da C (che sarà necessariamente una superclasse della classe di ricerca) alla classe di ricerca stessa.

JVM impone un requisito simile per invokespecial istruzioni, che l'argomento del ricevitore deve corrispondere sia al metodo <risolto em>che< alla> classe corrente. Anche in questo caso, questo requisito viene applicato restringendo il tipo del parametro iniziale all'handle del metodo risultante. Vedere la specifica della macchina virtuale Java, sezione 4.10.1.9.

La JVM rappresenta costruttori e blocchi di inizializzatore statici come metodi interni con nomi speciali ("<init>" e "<clinit>"). La sintassi interna delle istruzioni di chiamata consente loro di fare riferimento a metodi interni come se fossero metodi normali, ma il verificatore di bytecode JVM li rifiuta. Una ricerca di un metodo interno di questo tipo produrrà un oggetto NoSuchMethodException.

In alcuni casi, l'accesso tra classi annidate viene ottenuto dal compilatore Java creando un metodo wrapper per accedere a un metodo privato di un'altra classe nella stessa dichiarazione di primo livello. Ad esempio, una classe C.D annidata può accedere ai membri privati all'interno di altre classi correlate, ad Cesempio , C.D.Eo C.B, ma il compilatore Java potrebbe dover generare metodi wrapper in tali classi correlate. In questi casi, un Lookup oggetto su C.E non sarebbe in grado di tali membri privati. Una soluzione alternativa per questa limitazione è il Lookup#in Lookup.in metodo , che può trasformare una ricerca in C.E una delle altre classi, senza privilegi speciali.

Gli accessi consentiti a un determinato oggetto di ricerca possono essere limitati, in base al relativo set di #lookupModes lookupModes, a un subset di membri normalmente accessibili alla classe di ricerca. Ad esempio, il #publicLookup publicLookup metodo produce un oggetto di ricerca che può accedere solo ai membri pubblici nelle classi pubbliche. Il metodo #lookup lookup sensibile del chiamante produce un oggetto di ricerca con funzionalità complete relative alla relativa classe chiamante, per emulare tutti i comportamenti bytecode supportati. Inoltre, il Lookup#in Lookup.in metodo può produrre un oggetto di ricerca con meno modalità di accesso rispetto all'oggetto di ricerca originale.

<p style="font-size:smaller;"> " privacc"><em>Discussione dell'accesso privato:</em> Diciamo che una ricerca ha <em>accesso< privato/em> se le sue modalità di ricerca #lookupModes includono la possibilità di accedere ai private membri. Come documentato nei metodi pertinenti altrove, solo le ricerche con accesso privato dispongono delle funzionalità seguenti: <ul style="font-size:smaller;"><li>access private fields, methods, and constructors of the lookup class li create method handle which invoke caller sensitive methods, such as Class.forName<li>create method handle which Lookup#findSpecial emulate invokespecial instructions <li>avoid package access checks for classes accessible to the lookup class <<li>>create Lookup#in delegated lookup objects which have private access to other classes within the same package member </ul><p style="font-size: più piccolo;"> Ognuna di queste autorizzazioni è una conseguenza del fatto che un oggetto di ricerca con accesso privato può essere ricontracciato in modo sicuro a una classe di origine, i cui comportamenti bytecode e le autorizzazioni di accesso al linguaggio Java possono essere determinati ed emulati in modo affidabile dagli handle di metodo.

<h1>"secmgr">Security Manager interactions</h1> Sebbene le istruzioni bytecode possano fare riferimento solo alle classi in un caricatore di classi correlate, questa API può cercare metodi in qualsiasi classe, purché sia disponibile un riferimento al relativo Class oggetto. Tali riferimenti tra caricatori sono anche possibili con l'API Reflection core e sono impossibili da codificare istruzioni come invokestatic o getfield. È disponibile un'API di gestione della sicurezza java.lang.SecurityManager per consentire alle applicazioni di controllare tali riferimenti tra caricatori. Questi controlli si applicano sia all'API MethodHandles.Lookup che all'API Reflection Core (come trovato in java.lang.Class Class).

Se è presente un gestore della sicurezza, le ricerche dei membri sono soggette a controlli aggiuntivi. Da una a tre chiamate vengono effettuate al gestore della sicurezza. Una di queste chiamate può rifiutare l'accesso generando un oggetto java.lang.SecurityException SecurityException. Definire smgr come gestore della sicurezza, lookc come classe di ricerca dell'oggetto di ricerca corrente, refc come classe contenitore in cui viene cercato il membro e defc come classe in cui viene effettivamente definito il membro. Il valore lookc viene definito come <em>non presente</em> se l'oggetto di ricerca corrente non ha accesso privato. Le chiamate vengono effettuate in base alle regole seguenti: <ul><li><b>Passaggio 1:</b> Se lookc non è presente o se il caricatore di classe non è uguale a o a un predecessore del caricatore di classe di refc, SecurityManager#checkPackageAccess smgr.checkPackageAccess(refcPkg) viene chiamato , dove refcPkg è il pacchetto di refc. <li><b>Passaggio 2:</b> Se il membro recuperato non è pubblico e lookc non è presente, SecurityManager#checkPermission smgr.checkPermission viene chiamato con RuntimePermission("accessDeclaredMembers") . <li><b>Passaggio 3:</b> Se il membro recuperato non è pubblico e, se non è presente, e se defclookc e refc sono diversi, viene chiamato , SecurityManager#checkPackageAccess smgr.checkPackageAccess(defcPkg) dove defcPkg è il pacchetto di defc. <I controlli di sicurezza /ul> vengono eseguiti dopo il superamento di altri controlli di accesso. Di conseguenza, le regole precedenti presuppongono un membro pubblico o che viene eseguito l'accesso da una classe di ricerca con diritti per accedere al membro.

<h1"callsens">Caller sensitive methods/h1 A small number of Java methods have a special property called caller sensitivity.h1>"Caller sensitive methods</h1> A small number of Java methods have a special property called caller sensitivity. Un <metodo em>sensibile al< chiamante/em> può comportarsi in modo diverso a seconda dell'identità del chiamante immediato.

Se viene richiesto un handle di metodo per un metodo sensibile al chiamante, vengono applicate le regole generali per i comportamenti bytecode, ma prendono in considerazione la classe di ricerca in modo speciale. L'handle del metodo risultante si comporta come se fosse stato chiamato da un'istruzione contenuta nella classe di ricerca, in modo che il metodo sensibile al chiamante rilevi la classe di ricerca. Al contrario, l'invoker dell'handle del metodo viene ignorato. Pertanto, nel caso di metodi sensibili al chiamante, classi di ricerca diverse possono generare handle di metodo con comportamento diverso.

Nei casi in cui l'oggetto di ricerca è #publicLookup publicLookup()o un altro oggetto di ricerca senza accesso privato, la classe di ricerca viene ignorata. In questi casi, non è possibile creare alcun handle di metodo sensibile al chiamante, l'accesso non è consentito e la ricerca non riesce con un oggetto IllegalAccessException. <p style="font-size:smaller;"><em>Discussion:</em> , ad esempio, il metodo java.lang.Class#forName(String) Class.forName(x) sensibile al chiamante può restituire classi variabili o generare eccezioni variabili, a seconda del caricatore di classi della classe che la chiama. Una ricerca pubblica di Class.forName avrà esito negativo, perché non esiste un modo ragionevole per determinare il comportamento del bytecode. <p style="font-size:smaller;"> Se un'applicazione memorizza nella cache gli handle di metodi per la condivisione su larga scala, è consigliabile usarli publicLookup() per crearli. Se è presente una ricerca di Class.forName, l'operazione avrà esito negativo e l'applicazione deve intervenire in tal caso. Potrebbe essere che una ricerca successiva, forse durante la chiamata di un metodo bootstrap, possa incorporare l'identità specifica del chiamante, rendendo accessibile il metodo. <p style="font-size:smaller;"> La funzione MethodHandles.lookup è sensibile al chiamante in modo che sia possibile avere una base sicura per le ricerche. Quasi tutti gli altri metodi nell'API JSR 292 si basano su oggetti di ricerca per controllare le richieste di accesso.

Documentazione java per java.lang.invoke.MethodHandles.Lookup.

Le parti di questa pagina sono modifiche basate sul lavoro creato e condiviso dal progetto Open Source Android e usato in base ai termini descritti nella licenza Creative Commons 2.5 Attribuzione.

Campi

Package	Obsoleti. Maschera a bit singolo che rappresenta package l'accesso (accesso predefinito), che può contribuire al risultato di #lookupModes lookupModes.
Private	Obsoleti. Maschera a bit singolo che rappresenta private l'accesso, che può contribuire al risultato di #lookupModes lookupModes.
Protected	Obsoleti. Maschera a bit singolo che rappresenta protected l'accesso, che può contribuire al risultato di #lookupModes lookupModes.
Public	Obsoleti. Maschera a bit singolo che rappresenta public l'accesso, che può contribuire al risultato di #lookupModes lookupModes.

Proprietà

Class	Restituisce la classe di runtime di questo Objectoggetto . (Ereditato da Object)
Handle	Handle per l'istanza di Android sottostante. (Ereditato da Object)
JniIdentityHashCode	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
JniPeerMembers	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso.
PeerReference	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
ThresholdClass	Questa API supporta l'infrastruttura Mono per Android e non deve essere usata direttamente dal codice. (Ereditato da Object)
ThresholdType	Questa API supporta l'infrastruttura Mono per Android e non deve essere usata direttamente dal codice. (Ereditato da Object)

Metodi

Bind(Object, String, MethodType)	Produce un handle di metodo con associazione anticipata per un metodo non statico.
Clone()	Crea e restituisce una copia di questo oggetto. (Ereditato da Object)
Dispose()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
Dispose(Boolean)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
Equals(Object)	Indica se un altro oggetto è "uguale a" questo. (Ereditato da Object)
FindConstructor(Class, MethodType)	Produce un handle di metodo che crea un oggetto e lo inizializza utilizzando il costruttore del tipo specificato.
FindGetter(Class, String, Class)	Produce un handle di metodo che concede l'accesso in lettura a un campo non statico.
FindSetter(Class, String, Class)	Produce un handle di metodo che concede l'accesso in scrittura a un campo non statico.
FindSpecial(Class, String, MethodType, Class)	Produce un handle di metodo con associazione anticipata per un metodo virtuale.
FindStatic(Class, String, MethodType)	Produce un handle di metodo per un metodo statico.
FindStaticGetter(Class, String, Class)	Produce un handle di metodo che concede l'accesso in lettura a un campo statico.
FindStaticSetter(Class, String, Class)	Produce un handle di metodo che concede l'accesso in scrittura a un campo statico.
FindStaticVarHandle(Class, String, Class)	Produce un valore VarHandle che concede l'accesso a un campo name statico di tipo type dichiarato in una classe di tipo decl.
FindVarHandle(Class, String, Class)	Produce un valore VarHandle che concede l'accesso a un campo name non statico di tipo type dichiarato in una classe di tipo recv.
FindVirtual(Class, String, MethodType)	Produce un handle di metodo per un metodo virtuale.
GetHashCode()	Restituisce un valore del codice hash per l'oggetto. (Ereditato da Object)
In(Class)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso.
JavaFinalize()	Chiamato dal Garbage Collector su un oggetto quando Garbage Collection determina che non sono presenti altri riferimenti all'oggetto . (Ereditato da Object)
LookupClass()	Indica la classe che esegue la ricerca.
LookupModes()	Indica le classi di protezione dall'accesso dei membri che questo oggetto di ricerca può produrre.
Notify()	Riattiva un singolo thread in attesa del monitor dell'oggetto. (Ereditato da Object)
NotifyAll()	Riattiva tutti i thread in attesa del monitor dell'oggetto. (Ereditato da Object)
RevealDirect(MethodHandle)	Crea un handle di metodo diretto creato da questo oggetto di ricerca o da uno simile.
SetHandle(IntPtr, JniHandleOwnership)	Imposta la proprietà Handle. (Ereditato da Object)
ToArray<T>()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
ToString()	Restituisce una rappresentazione di stringa dell'oggetto. (Ereditato da Object)
Unreflect(Method)	Crea un handle di metodo diretto su m, se la classe di ricerca dispone dell'autorizzazione.
UnreflectConstructor(Constructor)	Produce un handle di metodo per un costruttore riflesso.
UnreflectGetter(Field)	Produce un handle di metodo che concede l'accesso in lettura a un campo riflesso.
UnreflectSetter(Field)	Produce un handle di metodo che concede l'accesso in scrittura a un campo riflesso.
UnreflectSpecial(Method, Class)	Produce un handle di metodo per un metodo riflesso.
UnreflectVarHandle(Field)	Produce un valore VarHandle che concede l'accesso a un campo f riflesso di tipo T dichiarato in una classe di tipo R.
UnregisterFromRuntime()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
Wait()	Fa sì che il thread corrente attenda finché non viene risvegliato, in genere ricevendo <>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 ricevendo>< una notifica</em> o <em>interrotto</em> o fino a quando non è trascorsa una determinata quantità di tempo reale. (Ereditato da Object)
Wait(Int64, Int32)	Fa sì che il thread corrente attenda finché non viene risvegliato, in genere ricevendo>< una notifica</em> o <em>interrotto</em> o fino a quando non è trascorsa una determinata quantità di tempo reale. (Ereditato da Object)

Implementazioni dell'interfaccia esplicita

IJavaPeerable.Disposed()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.DisposeUnlessReferenced()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.Finalized()	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.JniManagedPeerState	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.SetJniIdentityHashCode(Int32)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)
IJavaPeerable.SetPeerReference(JniObjectReference)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso. (Ereditato da Object)

Metodi di estensione

JavaCast<TResult>(IJavaObject)	Esegue una conversione del tipo di tipo controllato dal runtime Android.
JavaCast<TResult>(IJavaObject)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso.
GetJniTypeName(IJavaPeerable)	Un <oggetto< di ricerca em>/em> è una factory per la creazione di handle di metodo, quando la creazione richiede il controllo di accesso.