MethodHandles.Lookup Klasse

Referenz

Definition

Namespace:: Java.Lang.Invoke

Assembly:: Mono.Android.dll

Wichtig

Einige Informationen beziehen sich auf Vorabversionen, die vor dem Release ggf. grundlegend überarbeitet werden. Microsoft übernimmt hinsichtlich der hier bereitgestellten Informationen keine Gewährleistungen, seien sie ausdrücklich oder konkludent.

Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert.

[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

Vererbung: Object

Object
MethodHandles.Lookup

Attribute: RegisterAttribute

Hinweise

Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. Methodenhandles führen keine Zugriffsprüfungen durch, wenn sie aufgerufen werden, sondern wenn sie erstellt werden. Daher müssen Zugriffsbeschränkungen für Methodenhandles erzwungen werden, wenn ein Methodenhandle erstellt wird. Die Aufruferklasse, für die diese Einschränkungen erzwungen werden, wird als #lookupClass-Nachschlageklasse bezeichnet.

Eine Nachschlageklasse, die Methodenhandles erstellen muss, ruft auf #lookup MethodHandles.lookup , um eine Factory für sich selbst zu erstellen. Wenn das Lookup Factoryobjekt erstellt wird, wird die Identität der Nachschlageklasse bestimmt und sicher im Lookup -Objekt gespeichert. Die Nachschlageklasse (oder deren Delegaten) kann dann Factorymethoden für das Lookup Objekt verwenden, um Methodenhandles für zugriffsgeprüfte Member zu erstellen. Dies schließt alle Methoden, Konstruktoren und Felder ein, die für die Nachschlageklasse zulässig sind, auch private.

<h1>"lookups">Lookup Factory Methods</h1> Die Factorymethoden für ein Lookup Objekt entsprechen allen wichtigen Anwendungsfällen für Methoden, Konstruktoren und Felder. Jedes von einer Factory-Methode erstellte Methodenhandle ist das funktionale Äquivalent eines bestimmten <em-Bytecodeverhaltens></em>. (Das Bytecodeverhalten wird in Abschnitt 5.4.3.5 der Java Virtual Machine-Spezifikation beschrieben.) Hier ist eine Zusammenfassung der Übereinstimmung zwischen diesen Factorymethoden und dem Verhalten, das die resultierende Methode behandelt: <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<FT f;>/td td/td></td/td/td>>(T) this.f;<</tr><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;/<>tr<>td<>/td<>td<>java.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class) td>FT f;</td><td<>this.f = x;/><tr><tr<>tdjava.lang.invoke.MethodHandles.Lookup#findStaticSetter lookup.findStaticSetter(C.class,"f",FT.class)></td td><td br/td tdstatic<>><FT f; br/td td<><>C.f = arg;/td>><><<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><tr><td><java.lang.invoke.MethodHandles.Lookup#findStatic lookup.findStatic(C.class,"m",MT)/td><td><staticbr><T m(A*);/td><td><(T) C.m(arg*);/td></tr><tr><td><java.lang.invoke.MethodHandles.Lookup#findSpecial lookup.findSpecial(C.class,"m",MT,this.class)/td/td><td><T m(A*);/td td<(T) super.m(arg*);>/td></tr><><td><java.lang.invoke.MethodHandles.Lookup#findConstructor lookup.findConstructor(C.class,MT)/td><td><C(A*);/td><td/td>><new C(arg*);</tr><tr><td><java.lang.invoke.MethodHandles.Lookup#unreflectGetter lookup.unreflectGetter(aField)/td td><td>(static)?<><br><FT f;/td><td><(FT) aField.get(thisOrNull);/td></tr><tr><td><java.lang.invoke.MethodHandles.Lookup#unreflectSetter lookup.unreflectSetter(aField)/td td><td>(static)?<br><FT f;/td><td><aField.set(thisOrNull, arg);/td></tr><tr><td><java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)/td td><td>(static)?<br><T m(A*);/td><td>(T) aMethod.invoke(thisOrNull, arg*);</td></tr><td><>java.lang.invoke.MethodHandles.Lookup#unreflectConstructor lookup.unreflectConstructor(aConstructor)</td<>td<C(A*);>/td td/td><<> td><(C) aConstructor.newInstance(arg*);/tr<>td></td td<java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)>/td><td>(static)?<br><T m(A*);/td><td><(T) aMethod.invoke(thisOrNull, arg*);/td></tr></table>

Hier ist der Typ C die Klasse oder Schnittstelle, die nach einem Member gesucht wird und als Parameter mit dem Namen refc in den Nachschlagemethoden dokumentiert wird. Der Methodentyp MT setzt sich aus dem Rückgabetyp T und der Sequenz der Argumenttypen A*zusammen. Der Konstruktor verfügt auch über eine Sequenz von Argumenttypen A* und wird als Rückgabe des neu erstellten Objekts vom Typ angesehen C. Sowohl als auch MT der Feldtyp FT werden als Parameter mit dem Namen typedokumentiert. Der formale Parameter this steht für den Selbstverweis des Typs C; wenn er vorhanden ist, ist er immer das führende Argument für den Aufruf des Methodenhandles. (Bei einigen protected Membern this kann der Typ auf die Nachschlageklasse beschränkt sein; siehe unten.) Der Name arg steht für alle anderen Methodenhandleargumente. In den Codebeispielen für die Core Reflection-API steht der Name thisOrNull für einen NULL-Verweis, wenn die aufgerufene Methode oder das Feld statisch ist, andernfalls this . Die Namen aMethod, aFieldund aConstructor stehen für reflektierende Objekte, die den angegebenen Elementen entsprechen.

In Fällen, in denen der angegebene Member variablen Arity aufweist (d. h. eine Methode oder ein Konstruktor), ist der zurückgegebene Methodenhandle auch von MethodHandle#asVarargsCollector-Variablenaror arity. In allen anderen Fällen ist das zurückgegebene Methodenhandle von fester Authentifizierung. <p style="font-size:smaller;"><em>Discussion:</em> Die Äquivalenz zwischen nachgeahmten Methodenhandles und zugrunde liegenden Klassenmembern und Bytecodeverhalten kann auf verschiedene Arten unterteilt werden: <ul style="font-size:smaller;"><li>Wenn C über das Ladeprogramm der Nachschlageklasse nicht symbolisch zugegriffen werden kann, kann die Suche trotzdem erfolgreich sein, auch wenn kein entsprechender Java-Ausdruck oder bytecodierte Konstante vorhanden ist. <li>Ebenso kann der Nachschlagevorgang erfolgreich sein, wenn T oder MT nicht symbolisch vom Ladeprogramm der Nachschlageklasse aus zugänglich ist. Die Suche nach MethodHandle.invokeExact und MethodHandle.invoke ist beispielsweise immer erfolgreich, unabhängig vom angeforderten Typ. <li>Wenn ein Sicherheits-Manager installiert ist, kann er die Suche aus verschiedenen Gründen verbieten (siehe unten). Im Gegensatz dazu unterliegt die ldc Anweisung für eine CONSTANT_MethodHandle Konstante nicht den Überprüfungen des Sicherheits-Managers. <li>Wenn die nachgesuche Methode eine sehr große Arität aufweist, schlägt die Erstellung des Methodenhandles möglicherweise fehl, da der Methodenhandletyp zu viele Parameter aufweist. </ul>

<h1>"access">Zugriffsüberprüfung</h1> Zugriffsprüfungen werden in den Factorymethoden von Lookupangewendet, wenn ein Methodenhandle erstellt wird. Dies ist ein wesentlicher Unterschied zur Core Reflection-API, da java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke die Zugriffsüberprüfung für jeden Aufrufer bei jedem Aufruf durchgeführt wird.

Alle Zugriffsprüfungen beginnen mit einem Lookup -Objekt, das seine aufgezeichnete Nachschlageklasse mit allen Anforderungen zum Erstellen von Methodenhandles vergleicht. Ein einzelnes Lookup Objekt kann verwendet werden, um eine beliebige Anzahl von zugriffsgeprüften Methodenhandles zu erstellen, die alle für eine einzelne Nachschlageklasse überprüft werden.

Ein Lookup Objekt kann für anderen vertrauenswürdigen Code freigegeben werden, z. B. für ein Metaobjektprotokoll. Ein freigegebenes Lookup Objekt delegiert die Funktion zum Erstellen von Methodenhandles für private Member der Nachschlageklasse. Auch wenn privilegierter Code das Lookup -Objekt verwendet, ist die Zugriffsüberprüfung auf die Berechtigungen der ursprünglichen Nachschlageklasse beschränkt.

Ein Nachschlagevorgang kann fehlschlagen, da die enthaltende Klasse für die Nachschlageklasse nicht zugänglich ist, oder weil der gewünschte Klassenmember fehlt, oder weil der gewünschte Klassenmember für die Nachschlageklasse nicht zugänglich ist oder weil das Nachschlageobjekt nicht vertrauenswürdig genug ist, um auf den Member zuzugreifen. In jedem dieser Fälle wird von der versuchten Suche ein ReflectiveOperationException ausgelöst. Die genaue Klasse ist eine der folgenden: <ul><li>NoSuchMethodException — wenn eine Methode angefordert wird, aber nicht vorhanden <ist, li>NoSuchFieldException — wenn ein Feld angefordert wird, aber nicht vorhanden <ist li>IllegalAccessException — wenn der Member vorhanden ist, aber eine Zugriffsprüfung fehlschlägt </ul>

Im Allgemeinen sind die Bedingungen, unter denen ein Methodenhandle für eine Methode M gesucht werden kann, nicht restriktiver als die Bedingungen, unter denen die Nachschlageklasse einen Aufruf Mvon kompiliert, überprüft und aufgelöst haben könnte. Wenn die JVM Ausnahmen wie NoSuchMethodErrorauslöst, löst ein Methodenhandle-Lookup in der Regel eine entsprechende überprüfte Ausnahme aus, z. B NoSuchMethodException. . Und die Auswirkung des Aufrufs des Methodenhandles, das sich aus der Suche ergibt, entspricht genau der Ausführung des kompilierten, überprüften und aufgelösten Aufrufs von M. Der gleiche Punkt gilt für Felder und Konstruktoren. <p style="font-size:smaller;"><em>Discussion:</em> Access-Überprüfungen gelten nur für benannte und reflektierte Methoden, Konstruktoren und Felder. Andere Methoden behandeln Erstellungsmethoden, z MethodHandle#asType MethodHandle.asType. B. , erfordern keine Zugriffsprüfungen und werden unabhängig von jedem Lookup Objekt verwendet.

Wenn der gewünschte Member ist protected, gelten die üblichen JVM-Regeln, einschließlich der Anforderung, dass sich die Nachschlageklasse entweder im selben Paket wie das gewünschte Element befinden oder dieses Element erben muss. (Siehe Java Virtual Machine-Spezifikation, Abschnitte 4.9.2, 5.4.3.5 und 6.4.) Wenn es sich bei dem gewünschten Member um ein nicht statisches Feld oder eine methode in einem anderen Paket handelt, kann der resultierende Methodenhandle außerdem nur auf Objekte der Suchklasse oder einer ihrer Unterklassen angewendet werden. Diese Anforderung wird erzwungen, indem der Typ des führenden this Parameters von C (der notwendigerweise eine Superklasse der Nachschlageklasse sein wird) auf die Nachschlageklasse selbst beschränkt wird.

Die JVM stellt eine ähnliche Anforderung für invokespecial die Anweisung, dass das Empfängerargument sowohl mit der aufgelösten Methode <em>als< auch mit> der aktuellen Klasse übereinstimmen muss. Auch diese Anforderung wird erzwungen, indem der Typ des führenden Parameters auf das resultierende Methodenhandle beschränkt wird. (Siehe Java Virtual Machine Specification, Abschnitt 4.10.1.9.)

Die JVM stellt Konstruktoren und statische Initialisierungsblöcke als interne Methoden mit speziellen Namen ("<init>" und "<clinit>") dar. Die interne Syntax von Aufrufanweisungen ermöglicht es ihnen, auf solche internen Methoden zu verweisen, als ob es sich um normale Methoden handelt, aber die JVM-Bytecodeüberprüfung lehnt sie ab. Ein Nachschlagen einer solchen internen Methode führt zu einem NoSuchMethodException.

In einigen Fällen wird der Zugriff zwischen geschachtelten Klassen vom Java-Compiler abgerufen, indem eine Wrappermethode erstellt wird, um auf eine private Methode einer anderen Klasse in derselben Deklaration der obersten Ebene zuzugreifen. Beispielsweise kann eine geschachtelte Klasse C.D auf private Member in anderen verwandten Klassen wie C, C.D.Eoder C.Bzugreifen, aber der Java-Compiler muss möglicherweise Wrappermethoden in diesen verwandten Klassen generieren. In solchen Fällen kann ein Lookup Objekt auf C.E diese privaten Member nicht mehr verwendet werden. Eine Problemumgehung für diese Einschränkung ist die -Methode, mit der Lookup#in Lookup.in ein Lookup für C.E eine dieser anderen Klassen ohne besondere Rechteerweiterung in eine dieser anderen Klassen transformiert werden kann.

Die auf ein bestimmtes Nachschlageobjekt zulässigen Zugriffe können gemäß seiner Gruppe von #lookupModes lookupModesauf eine Teilmenge von Elementen beschränkt sein, auf die normalerweise für die Nachschlageklasse zugegriffen werden kann. Die Methode erzeugt beispielsweise ein Nachschlageobjekt, #publicLookup publicLookup das nur für den Zugriff auf öffentliche Member in öffentlichen Klassen zulässig ist. Die sensible Methode #lookup lookup des Aufrufers erzeugt ein Nachschlageobjekt mit vollständigen Funktionen relativ zur Aufruferklasse, um alle unterstützten Bytecodeverhalten zu emulieren. Außerdem kann die Lookup#in Lookup.in -Methode ein Nachschlageobjekt mit weniger Zugriffsmodi als das ursprüngliche Nachschlageobjekt erzeugen.

<p style="font-size:smaller;"> " privacc"><em>Diskussion über den privaten Zugriff:</em> Wir sagen, dass ein Lookup einen privaten Zugriff< hat<>,> wenn seine #lookupModes Nachschlagemodi die Möglichkeit des Zugriffs auf private Mitglieder beinhalten. Wie in den entsprechenden Methoden an anderer Stelle dokumentiert, verfügen nur Nachschlagevorgänge mit privatem Zugriff über die folgenden Funktionen: <ul style="font-size:smaller;"><li>access private Felder, Methoden und Konstruktoren der Nachschlageklasse <li>create-Methode behandelt, die aufruferempfindliche Methoden aufrufen, z. B Class.forName<. die li>create-Methode verarbeitet, welche Lookup#findSpecial emulate invokespecial Anweisungen <li>vermeidet Paketzugriffsprüfungen für Klassen, die für die Nachschlageklasse <li>create Lookup#in delegated lookup objects zugänglich sind, die privaten Zugriff auf andere Klassen innerhalb desselben Paketmembers </ul><p style="font-size haben: kleiner;"> Jede dieser Berechtigungen ist eine Folge der Tatsache, dass ein Nachschlageobjekt mit privatem Zugriff sicher zu einer Ursprungsklasse zurückverfolgt werden kann, deren Bytecodeverhalten und Java-Sprachzugriffsberechtigungen zuverlässig von Methodenhandles bestimmt und emuliert werden können.

<h1>"secmgr">Security Manager interactions</h1> Bytecodeanweisungen können zwar nur auf Klassen in einem verknüpften Klassenladeprogramm verweisen, diese API kann jedoch in jeder Klasse nach Methoden suchen, solange ein Verweis auf das zugehörige Class Objekt verfügbar ist. Solche Querladeerverweise sind auch mit der Core-Reflexions-API möglich und sind nicht möglich, Anweisungen wie invokestatic oder getfieldzu bytecoden. Es gibt eine java.lang.SecurityManager-Sicherheits-Manager-API, mit der Anwendungen solche Querladeerverweise überprüfen können. Diese Überprüfungen gelten sowohl für die MethodHandles.Lookup API als auch für die Kernreflektions-API (wie unter java.lang.Class Class).

Wenn ein Sicherheits-Manager vorhanden ist, werden member lookups zusätzlichen Überprüfungen unterzogen. Es werden ein bis drei Anrufe an den Sicherheitsmanager getätigt. Jeder dieser Aufrufe kann den Zugriff verweigern, indem ein java.lang.SecurityException SecurityExceptionausgelöst wird. Definieren Sie smgr als Sicherheits-Manager, lookc als Nachschlageklasse des aktuellen Nachschlageobjekts, als enthaltende Klasse, refc in der der Member gesucht wird, und defc als die Klasse, in der der Member tatsächlich definiert ist. Der Wert lookc wird als <em>not present</em> definiert, wenn das aktuelle Nachschlageobjekt keinen privaten Zugriff hat. Die Aufrufe erfolgen nach den folgenden Regeln: <ul><li><b>Schritt 1:</b> Wenn lookc nicht vorhanden ist, oder wenn sein Klassenladeprogramm nicht mit oder einem Vorgänger des Klassenladeprogramms von refcidentisch ist, wird dann SecurityManager#checkPackageAccess smgr.checkPackageAccess(refcPkg) aufgerufen, wobei refcPkg das Paket von refcist. <li><b>Schritt 2:</b> Wenn der abgerufene Member nicht öffentlich lookc und nicht vorhanden ist, SecurityManager#checkPermission smgr.checkPermission wird mit RuntimePermission("accessDeclaredMembers") aufgerufen. <li><b>Schritt 3:</b> Wenn der abgerufene Member nicht öffentlich ist und nicht lookc vorhanden ist, und wenn defc und refc unterschiedlich sind, wird aufgerufen SecurityManager#checkPackageAccess smgr.checkPackageAccess(defcPkg) , wobei defcPkg das Paket von defcist. </ul> Sicherheitsüberprüfungen werden ausgeführt, nachdem andere Zugriffsprüfungen bestanden haben. Daher setzen die obigen Regeln ein Element voraus, das öffentlich ist, oder auf das von einer Nachschlageklasse aus zugegriffen wird, die über Rechte für den Zugriff auf den Member verfügt.

<h1>"callsens">Caller sensitive methods</h1> Eine kleine Anzahl von Java-Methoden verfügt über eine spezielle Eigenschaft namens Aufrufersensitivität. Eine <em-aufrufer-sensitive></em-Methode> kann sich je nach Identität des unmittelbaren Aufrufers unterschiedlich verhalten.

Wenn ein Methodenhandle für eine aufrufersensitive Methode angefordert wird, gelten die allgemeinen Regeln für Bytecodeverhalten, aber sie berücksichtigen die Nachschlageklasse in besonderer Weise. Das resultierende Methodenhandle verhält sich so, als würde er von einer Anweisung aufgerufen, die in der Nachschlageklasse enthalten ist, sodass die aufrufersensitive Methode die Nachschlageklasse erkennt. (Im Gegensatz dazu wird der Aufrufer des Methodenhandles ignoriert.) Daher können bei aufrufersensitiven Methoden verschiedene Nachschlageklassen dazu führen, dass sich Methodenhandles unterschiedlich verhalten.

In Fällen, in denen das Nachschlageobjekt oder ein anderes Nachschlageobjekt ohne privaten Zugriff ist #publicLookup publicLookup(), wird die Nachschlageklasse nicht berücksichtigt. In solchen Fällen kann kein aufrufersensitives Methodenhandle erstellt werden, der Zugriff ist verboten, und die Suche schlägt mit einem fehl IllegalAccessException. <p style="font-size:smaller;"><em>Discussion:</em> Beispielsweise kann die aufrufersensitive Methode java.lang.Class#forName(String) Class.forName(x) je nach Klassenladeprogramm der Klasse, die sie aufruft, unterschiedliche Klassen zurückgeben oder unterschiedliche Ausnahmen auslösen. Eine öffentliche Suche von Class.forName schlägt fehl, da es keine vernünftige Möglichkeit gibt, das Bytecodeverhalten zu bestimmen. <p style="font-size:smaller;"> Wenn eine Anwendung eine Methode für die umfassende Freigabe zwischenspeichert, sollte sie sie verwenden publicLookup() , um sie zu erstellen. Wenn es eine Suche von Class.forNamegibt, schlägt dies fehl, und die Anwendung muss in diesem Fall geeignete Maßnahmen ergreifen. Es kann sein, dass ein späterer Nachschlagevorgang, etwa während des Aufrufs einer Bootstrap-Methode, die spezifische Identität des Aufrufers einbeziehen kann, sodass die Methode zugänglich ist. <p style="font-size:smaller;"> Die Funktion MethodHandles.lookup ist aufruferempfindlich, sodass eine sichere Grundlage für Nachschlagevorgänge vorhanden sein kann. Fast alle anderen Methoden in der JSR 292-API basieren auf Nachschlageobjekten, um Zugriffsanforderungen zu überprüfen.

Java-Dokumentation für java.lang.invoke.MethodHandles.Lookup.

Teile dieser Seite sind Änderungen, die auf Arbeiten basieren, die vom Android Open Source Project erstellt und freigegeben wurden und gemäß den In der Attribution License beschriebenen Begriffen verwendet werden.

Felder

Package	Veraltet. Eine Single-Bit-Maske, die den Zugriff (Standardzugriff) darstellt `package` , die zum Ergebnis von `#lookupModes lookupModes`beitragen kann.
Private	Veraltet. Eine Ein-Bit-Maske, die den Zugriff darstellt `private` , die zum Ergebnis von `#lookupModes lookupModes`beitragen kann.
Protected	Veraltet. Eine Ein-Bit-Maske, die den Zugriff darstellt `protected` , die zum Ergebnis von `#lookupModes lookupModes`beitragen kann.
Public	Veraltet. Eine Ein-Bit-Maske, die den Zugriff darstellt `public` , die zum Ergebnis von `#lookupModes lookupModes`beitragen kann.

Eigenschaften

Class	Gibt die Laufzeitklasse dieses `Object`zurück. (Geerbt von Object)
Handle	Das Handle zum zugrunde liegenden Android-instance. (Geerbt von Object)
JniIdentityHashCode	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
JniPeerMembers	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert.
PeerReference	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
ThresholdClass	Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen. (Geerbt von Object)
ThresholdType	Diese API unterstützt die Mono für Android-Infrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code vorgesehen. (Geerbt von Object)

Methoden

Bind(Object, String, MethodType)	Erzeugt einen früh gebundenen Methodenhandle für eine nicht statische Methode.
Clone()	Erstellt und gibt eine Kopie dieses Objekts zurück. (Geerbt von Object)
Dispose()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
Dispose(Boolean)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
Equals(Object)	Gibt an, ob ein anderes Objekt diesem "gleich" ist. (Geerbt von Object)
FindConstructor(Class, MethodType)	Erzeugt ein Methodenhandle, das ein -Objekt erstellt und initialisiert, wobei der Konstruktor des angegebenen Typs verwendet wird.
FindGetter(Class, String, Class)	Erzeugt einen Methodenhandle, der Lesezugriff auf ein nicht statisches Feld ermöglicht.
FindSetter(Class, String, Class)	Erzeugt einen Methodenhandle, der Schreibzugriff auf ein nicht statisches Feld ermöglicht.
FindSpecial(Class, String, MethodType, Class)	Erzeugt einen früh gebundenen Methodenhandle für eine virtuelle Methode.
FindStatic(Class, String, MethodType)	Erzeugt einen Methodenhandle für eine statische Methode.
FindStaticGetter(Class, String, Class)	Erzeugt einen Methodenhandle, der Lesezugriff auf ein statisches Feld ermöglicht.
FindStaticSetter(Class, String, Class)	Erzeugt einen Methodenhandle, der Schreibzugriff auf ein statisches Feld ermöglicht.
FindStaticVarHandle(Class, String, Class)	Erzeugt ein VarHandle, das Zugriff auf ein statisches Feld `name` vom Typ `type` gibt, das in einer Klasse vom Typ `decl`deklariert ist.
FindVarHandle(Class, String, Class)	Erzeugt ein VarHandle, das Zugriff auf ein nicht statisches Feld `name` vom Typ `type` gibt, das in einer Klasse des Typs `recv`deklariert ist.
FindVirtual(Class, String, MethodType)	Erzeugt ein Methodenhandle für eine virtuelle Methode.
GetHashCode()	Gibt einen Hashcodewert für das Objekt zurück. (Geerbt von Object)
In(Class)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert.
JavaFinalize()	Wird vom Garbage Collector für ein Objekt aufgerufen, wenn die Garbage Collection feststellt, dass keine Verweise mehr auf das Objekt vorhanden sind. (Geerbt von Object)
LookupClass()	Gibt an, welche Klasse die Suche durchführt.
LookupModes()	Gibt an, welche Zugriffsschutzklassen von Membern dieses Nachschlageobjekts erzeugen kann.
Notify()	Aktiviert einen einzelnen Thread, der auf dem Monitor dieses Objekts wartet. (Geerbt von Object)
NotifyAll()	Aktiviert alle Threads, die auf dem Monitor dieses Objekts warten. (Geerbt von Object)
RevealDirect(MethodHandle)	Bricht ein direktes Methodenhandle, das von diesem Oder einem ähnlichen Nachschlageobjekt erstellt wurde.
SetHandle(IntPtr, JniHandleOwnership)	Legt die Handle-Eigenschaft fest. (Geerbt von Object)
ToArray<T>()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
ToString()	Gibt eine Zeichenfolgendarstellung des Objekts zurück. (Geerbt von Object)
Unreflect(Method)	Stellt eine direkte Methode für m her, wenn die Nachschlageklasse über die Berechtigung verfügt.
UnreflectConstructor(Constructor)	Erzeugt ein Methodenhandle für einen reflektierten Konstruktor.
UnreflectGetter(Field)	Erzeugt einen Methodenhandle, der Lesezugriff auf ein reflektiertes Feld ermöglicht.
UnreflectSetter(Field)	Erzeugt einen Methodenhandle, der Schreibzugriff auf ein reflektiertes Feld ermöglicht.
UnreflectSpecial(Method, Class)	Erzeugt einen Methodenhandle für eine reflektierte Methode.
UnreflectVarHandle(Field)	Erzeugt ein VarHandle, das Zugriff auf ein reflektiertes Feld `f` vom Typ `T` gibt, das in einer Klasse vom Typ `R`deklariert ist.
UnregisterFromRuntime()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
Wait()	Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel durch em benachrichtigen/em> oder <em>interrupted</em>.<>< (Geerbt von Object)
Wait(Int64)	Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel, indem <er>benachrichtigt</em> oder <em>interrupted</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object)
Wait(Int64, Int32)	Bewirkt, dass der aktuelle Thread wartet, bis er aktiviert wird, in der Regel, indem <er>benachrichtigt</em> oder <em>interrupted</em> oder bis eine bestimmte Menge an Echtzeit verstrichen ist. (Geerbt von Object)

Explizite Schnittstellenimplementierungen

IJavaPeerable.Disposed()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.DisposeUnlessReferenced()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.Finalized()	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.JniManagedPeerState	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.SetJniIdentityHashCode(Int32)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)
IJavaPeerable.SetPeerReference(JniObjectReference)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert. (Geerbt von Object)

Erweiterungsmethoden

JavaCast<TResult>(IJavaObject)	Führt eine Für Android-Runtime überprüfte Typkonvertierung aus.
JavaCast<TResult>(IJavaObject)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert.
GetJniTypeName(IJavaPeerable)	Ein <em-Lookup-Objekt></em> ist eine Factory zum Erstellen von Methodenhandles, wenn die Erstellung eine Zugriffsüberprüfung erfordert.

Gilt für: