MethodHandles.Lookup Classe

Définition

Espace de noms:

Java.Lang.Invoke

Assembly:

Mono.Android.dll

Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès.

[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

Héritage

Object

Object

MethodHandles.Lookup

Attributs

RegisterAttribute

Remarques

Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. Les handles de méthode n’effectuent pas de vérifications d’accès lorsqu’ils sont appelés, mais plutôt lorsqu’ils sont créés. Par conséquent, les restrictions d’accès de handle de méthode doivent être appliquées lorsqu’un handle de méthode est créé. La classe d’appelant sur laquelle ces restrictions sont appliquées est appelée classe de recherche #lookupClass.

Une classe de recherche qui doit créer des handles de méthode appellera #lookup MethodHandles.lookup pour créer une fabrique pour elle-même. Lorsque l’objet Lookup de fabrique est créé, l’identité de la classe de recherche est déterminée et stockée en toute sécurité dans l’objet Lookup . La classe de recherche (ou ses délégués) peut ensuite utiliser des méthodes de fabrique sur l’objet Lookup pour créer des handles de méthode pour les membres vérifiés par accès. Cela inclut toutes les méthodes, constructeurs et champs autorisés à la classe de recherche, même privés.

<h1>"lookups">Lookup Factory Methods</h1> Les méthodes de fabrique d’un Lookup objet correspondent à tous les cas d’usage majeurs pour les méthodes, les constructeurs et les champs. Chaque handle de méthode créé par une méthode de fabrique est l’équivalent fonctionnel d’un comportement</em bytecode em>> particulier<. (Les comportements bytecode sont décrits dans la section 5.4.3.5 de la spécification de machine virtuelle Java.) Voici un résumé de la correspondance entre ces méthodes de fabrique et le comportement des handles de méthode résultants : <table border=1 cellpadding=5 summary="lookup method behaviors"><tr><th>"equiv"equiv">lookup expression</th<><> th<>>bytecode behavior</th></tr><tr><tdjava.lang.invoke.MethodHandles.Lookup#findGetter lookup.findGetter(C.class,"f",FT.class)></td><>><><<(T) this.f;FT f;/td/tr/tr/tr><><tr><td>java.lang.invoke.MethodHandles.Lookup#findStaticGetter lookup.findStaticGetter(C.class,"f",FT.class)</<static>><td td br>FT f;</td td>(T) C.f;</td></td></tr tr<>>java.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class)<>< td/this.f = x;><><td<><>FT f;/td/td></tr tr><<>td><java.lang.invoke.MethodHandles.Lookup#findStaticSetter lookup.findStaticSetter(C.class,"f",FT.class)/td td><static/><td td br<>FT f;/td tdC.f = arg;></td></td></tr><><><java.lang.invoke.MethodHandles.Lookup#findVirtual lookup.findVirtual(C.class,"m",MT)td/><><T m(A*);td td/td><><(T) this.m(arg*);/<>tr tr>><<td><java.lang.invoke.MethodHandles.Lookup#findStatic lookup.findStatic(C.class,"m",MT)/td>>static<><T m(A*);< br/td><(T) C.m(arg*);>< td/td<>/tr tr<<>>td>java.lang.invoke.MethodHandles.Lookup#findSpecial lookup.findSpecial(C.class,"m",MT,this.class)</>><<T m(A*);td/td/td/td(T) super.m(arg*);<>/td></td></tr/tr><>><<java.lang.invoke.MethodHandles.Lookup#findConstructor lookup.findConstructor(C.class,MT)td/><C(A*);<>td/td/td>>><<<new C(arg*);/tr tr>><</java.lang.invoke.MethodHandles.Lookup#unreflectGetter lookup.unreflectGetter(aField)><td<>>(static) ?<br>FT f;</td><><(FT) aField.get(thisOrNull);/td/td<>/tr tr><><td<>java.lang.invoke.MethodHandles.Lookup#unreflectSetter lookup.unreflectSetter(aField)/td><>(static) ?<br>FT f;</td><><aField.set(thisOrNull, arg);/td/td<>/tr tr><><td<>java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)/td><>(static) ?<br>T m(A*);</td><<>(T) aMethod.invoke(thisOrNull, arg*);/td/td></tr tr<<>>td<java.lang.invoke.MethodHandles.Lookup#unreflectConstructor lookup.unreflectConstructor(aConstructor)>/td>><<C(A*);/td/td>><<><(C) aConstructor.newInstance(arg*);/td/tr tr>><<<>java.lang.invoke.MethodHandles.Lookup#unreflect lookup.unreflect(aMethod)/td>><(static) ?<br><T m(A*);/td></>(T) aMethod.invoke(thisOrNull, arg*);<td/td<>/tr></table>

Ici, le type C est la classe ou l’interface recherchée pour un membre, documentée comme paramètre nommé refc dans les méthodes de recherche. Le type MT de méthode est composé du type T de retour et de la séquence de types d’arguments A*. Le constructeur a également une séquence de types A* d’arguments et est considéré comme renvoyant l’objet nouvellement créé de type C. Le MT type de champ et le type FT de champ sont documentés sous la forme d’un paramètre nommé type. Le paramètre this formel correspond à l’auto-référence de type C; s’il est présent, il s’agit toujours de l’argument de début de l’appel de handle de méthode. (Dans le cas de certains protected membres, this peut être limité en type à la classe de recherche ; voir ci-dessous.) Le nom arg correspond à tous les autres arguments de handle de méthode. Dans les exemples de code de l’API Core Reflection, le nom thisOrNull correspond à une référence null si la méthode ou le champ accédé est statique, et this sinon. aMethodNoms , aFieldet aConstructor stand pour les objets réfléchissants correspondant aux membres donnés.

Dans les cas où le membre donné est d’arité variable (par exemple, une méthode ou un constructeur), le handle de méthode retourné sera également de MethodHandle#asVarargsCollector variable arity. Dans tous les autres cas, le handle de méthode retourné sera d’arité fixe. <p style="font-size :smaller ; »><em>Discussion :</em> L’équivalence entre les handles de méthode recherchés et les membres de classe sous-jacents et les comportements bytecode peuvent se décomposer de plusieurs façons : <ul style="font-size :smaller ; »><li>If C n’est pas symboliquement accessible à partir du chargeur de la classe de recherche, la recherche peut toujours réussir, même s’il n’existe aucune expression Java équivalente ou constante bytecoded. <li>De même, si T elle MT n’est pas symboliquement accessible à partir du chargeur de la classe de recherche, la recherche peut toujours réussir. Par exemple, les recherches pour MethodHandle.invokeExact et MethodHandle.invoke réussissent toujours, quel que soit le type demandé. <li>S’il existe un gestionnaire de sécurité installé, il peut interdire la recherche sur différents motifs (voir ci-dessous). En revanche, l’instruction ldc sur une CONSTANT_MethodHandle constante n’est pas soumise aux vérifications du gestionnaire de sécurité. <li>Si la méthode recherchée a une très grande arité, la création du handle de méthode peut échouer, en raison du type de handle de méthode ayant trop de paramètres. </ul>

<h1>"access">Access checking</h1> Access checks are applied in the factory methods of Lookup, when a method handle is created. Il s’agit d’une différence clé par rapport à l’API Core Reflection, car java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke effectue la vérification d’accès sur chaque appelant, sur chaque appel.

Toutes les vérifications d’accès commencent à partir d’un Lookup objet, qui compare sa classe de recherche enregistrée à toutes les requêtes pour créer des handles de méthode. Un seul Lookup objet peut être utilisé pour créer n’importe quel nombre de handles de méthode vérifiés par accès, tous vérifiés par rapport à une seule classe de recherche.

Un Lookup objet peut être partagé avec d’autres codes approuvés, tels qu’un protocole metaobject. Un objet partagé Lookup délègue la possibilité de créer des handles de méthode sur des membres privés de la classe de recherche. Même si le code privilégié utilise l’objet Lookup , la vérification d’accès est limitée aux privilèges de la classe de recherche d’origine.

Une recherche peut échouer, car la classe conteneur n’est pas accessible à la classe de recherche, ou parce que le membre de classe souhaité est manquant, ou parce que le membre de classe souhaité n’est pas accessible à la classe de recherche, ou parce que l’objet de recherche n’est pas suffisamment approuvé pour accéder au membre. Dans l’un de ces cas, une ReflectiveOperationException exception est levée à partir de la recherche tentée. La classe exacte sera l’une des suivantes : <ul><li>noSuchMethodException &mdash ; si une méthode est demandée mais n’existe <pas li>NoSuchFieldException &mdash ; si un champ est demandé, mais n’existe <pas li>IllegalAccessException &mdash ; si le membre existe mais qu’une vérification d’accès échoue </ul>

En général, les conditions dans lesquelles un handle de méthode peut être recherché pour une méthode M ne sont pas plus restrictives que les conditions dans lesquelles la classe de recherche pourrait avoir compilé, vérifié et résolu un appel à M. Lorsque la machine virtuelle JVM déclenche des exceptions comme NoSuchMethodError, une recherche de handle de méthode déclenche généralement une exception vérifiée correspondante, telle que NoSuchMethodException. Et l’effet de l’appel du handle de méthode résultant de la recherche est exactement équivalent à l’exécution de l’appel compilé, vérifié et résolu à M. Le même point est vrai pour les champs et les constructeurs. <p style="font-size :smaller ; »><em>Discussion :</em> Access vérifie uniquement s’applique aux méthodes nommées et reflétées, aux constructeurs et aux champs. D’autres méthodes de gestion de méthode, telles que MethodHandle#asType MethodHandle.asType, ne nécessitent aucune vérification d’accès et sont utilisées indépendamment de n’importe quel Lookup objet.

Si le membre souhaité est protected, les règles JVM habituelles s’appliquent, y compris la condition que la classe de recherche doit être dans le même package que le membre souhaité, ou doit hériter de ce membre. (Consultez la spécification des machines virtuelles Java, sections 4.9.2, 5.4.3.5 et 6.4.) En outre, si le membre souhaité est un champ ou une méthode non statique dans un autre package, le handle de méthode résultant peut uniquement être appliqué aux objets de la classe de recherche ou à l’une de ses sous-classes. Cette exigence est appliquée en limitant le type du paramètre de début this ( C qui sera nécessairement une superclasse de la classe de recherche) à la classe de recherche elle-même.

La machine virtuelle JVM impose une exigence similaire à l’instruction invokespecial , que l’argument récepteur doit correspondre à la fois à la méthode <résolue em>et</em> à la classe actuelle. Là encore, cette exigence est appliquée en limitant le type du paramètre de début au handle de méthode résultant. (Consultez la spécification de machine virtuelle Java, section 4.10.1.9.)

La machine virtuelle JVM représente des constructeurs et des blocs d’initialiseurs statiques en tant que méthodes internes avec des noms spéciaux ("<init>" et "<clinit>"). La syntaxe interne des instructions d’appel leur permet de faire référence à ces méthodes internes comme si elles étaient des méthodes normales, mais le vérificateur de code bytecode JVM les rejette. Une recherche de cette méthode interne produit un NoSuchMethodException.

Dans certains cas, l’accès entre les classes imbriquées est obtenu par le compilateur Java en créant une méthode wrapper pour accéder à une méthode privée d’une autre classe dans la même déclaration de niveau supérieur. Par exemple, une classe C.D imbriquée peut accéder aux membres privés dans d’autres classes associées telles que C, C.D.Eou C.B, mais le compilateur Java peut avoir besoin de générer des méthodes wrapper dans ces classes associées. Dans ce cas, un Lookup objet sur C.E serait incapable de ces membres privés. Une solution de contournement pour cette limitation est la Lookup#in Lookup.in méthode, qui peut transformer une recherche sur C.E l’une de ces autres classes, sans élévation de privilège spéciale.

Les accès autorisés à un objet de recherche donné peuvent être limités, selon son ensemble , #lookupModes lookupModesà un sous-ensemble de membres normalement accessible à la classe de recherche. Par exemple, la #publicLookup publicLookup méthode produit un objet de recherche qui est uniquement autorisé à accéder aux membres publics dans les classes publiques. La méthode #lookup lookup sensible de l’appelant produit un objet de recherche avec des fonctionnalités complètes par rapport à sa classe d’appelant, pour émuler tous les comportements de code bytecode pris en charge. En outre, la Lookup#in Lookup.in méthode peut produire un objet de recherche avec moins de modes d’accès que l’objet de recherche d’origine.

<p style="font-size :smaller ; » »> Privecc"><em>Discussion of private access :</em> We say that a>< em private access</em> if its #lookupModes lookup modes include the possibilité d’accéder aux private membres. Comme indiqué dans les méthodes pertinentes ailleurs, seules les recherches avec accès privé possèdent les fonctionnalités suivantes : <ul style="font-size :smaller ; »><li>access private fields, methods, and constructors of the lookup class <li>create method handles qui appellent des méthodes sensibles de l’appelant, comme<Class.forName li>create method handles 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 qui ont un accès privé à d’autres classes dans le même membre <de package /ul><p style="font-size : plus petit ;"> Chacune de ces autorisations est une conséquence du fait qu’un objet de recherche disposant d’un accès privé peut être suivi de manière sécurisée vers une classe d’origine, dont les comportements bytecode et les autorisations d’accès au langage Java peuvent être déterminés et émulés de manière fiable par les handles de méthode.

<h1>"secmgr">Interactions du gestionnaire de sécurité/h1> Bien que les instructions bytecode ne puissent faire référence qu’aux classes d’un chargeur de classes connexes<, cette API peut rechercher des méthodes dans n’importe quelle classe, tant qu’une référence à son Class objet est disponible. Ces références cross-loader sont également possibles avec l’API Core Reflection et sont impossibles à bytecoder des instructions telles que invokestatic ou getfield. Il existe une API du gestionnaire de sécurité java.lang.SecurityManager pour permettre aux applications de vérifier ces références inter-chargeurs. Ces vérifications s’appliquent à la fois à l’API MethodHandles.Lookup et à l’API Core Reflection (comme indiqué sur java.lang.Class Class).

Si un gestionnaire de sécurité est présent, les recherches de membres sont soumises à des vérifications supplémentaires. De un à trois appels sont effectués au gestionnaire de sécurité. L’un de ces appels peut refuser l’accès en lève un java.lang.SecurityException SecurityException. Définissez smgr comme gestionnaire de sécurité, lookc comme classe de recherche de l’objet de recherche actuel, refc comme classe contenante dans laquelle le membre est recherché, et defc comme classe dans laquelle le membre est réellement défini. La valeur lookc est définie comme <em>non présente</em> si l’objet de recherche actuel n’a pas d’accès privé. Les appels sont effectués en fonction des règles suivantes : <ul><li><b>Step 1 :</b> If lookc is not present, or if its class loader is not the same as or an ancestor of the class loader of refc, then SecurityManager#checkPackageAccess smgr.checkPackageAccess(refcPkg) is called, where refcPkg is the package of refc. <Li><b>Étape 2 :</b> Si le membre récupéré n’est pas public et lookc n’est pas présent, avec SecurityManager#checkPermission smgr.checkPermission RuntimePermission("accessDeclaredMembers") est appelé. <li><b>Étape 3 :</b> Si le membre récupéré n’est pas public, et s’il lookc n’est pas présent, et si defc et refc sont différents, est SecurityManager#checkPackageAccess smgr.checkPackageAccess(defcPkg) appelé, où defcPkg est le package de defc. <Les vérifications de sécurité /ul> sont effectuées une fois les autres vérifications d’accès passées. Par conséquent, les règles ci-dessus présupposent un membre qui est public ou qui est accessible à partir d’une classe de recherche qui a les droits d’accès au membre.

<h1>"callsens">Caller sensitive methods</h1> A small number of Java methods have a special property called caller sensitivity. >Une <méthode em caller-sensitive</em> peut se comporter différemment en fonction de l’identité de son appelant immédiat.

Si un handle de méthode pour une méthode sensible à l’appelant est demandé, les règles générales pour les comportements bytecode s’appliquent, mais elles prennent en compte la classe de recherche d’une manière spéciale. Le handle de méthode résultant se comporte comme s’il était appelé à partir d’une instruction contenue dans la classe de recherche, afin que la méthode sensible à l’appelant détecte la classe de recherche. (En revanche, l’appelant du handle de méthode est ignoré.) Ainsi, dans le cas de méthodes sensibles à l’appelant, différentes classes de recherche peuvent donner lieu à des handles de méthode différemment de comportement.

Dans les cas où l’objet de recherche est #publicLookup publicLookup(), ou un autre objet de recherche sans accès privé, la classe de recherche est ignorée. Dans ce cas, aucun handle de méthode sensible à l’appelant ne peut être créé, l’accès est interdit et la recherche échoue avec un IllegalAccessException. <p style="font-size :smaller ; »><em>Discussion :</em> Par exemple, la méthode java.lang.Class#forName(String) Class.forName(x) sensible à l’appelant peut retourner des classes variables ou lever des exceptions variables, en fonction du chargeur de classes de la classe qui l’appelle. Une recherche publique échoue Class.forName , car il n’existe aucun moyen raisonnable de déterminer son comportement de code bytecode. <p style="font-size :smaller ; »> Si une application met en cache la méthode gère le partage à grande échelle, elle doit l’utiliser publicLookup() pour les créer. S’il existe une recherche, Class.forNameelle échoue et l’application doit prendre les mesures appropriées dans ce cas. Il peut s’agir d’une recherche ultérieure, peut-être pendant l’appel d’une méthode bootstrap, peut incorporer l’identité spécifique de l’appelant, ce qui rend la méthode accessible. <p style="font-size :smaller ; »> La fonction MethodHandles.lookup est sensible à l’appelant afin qu’il puisse y avoir une base sécurisée pour les recherches. Presque toutes les autres méthodes de l’API JSR 292 s’appuient sur des objets de recherche pour vérifier les demandes d’accès.

Documentation Java pour java.lang.invoke.MethodHandles.Lookup.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par le projet Android Open Source et utilisés en fonction des termes décrits dans la licence d’attribution Creative Commons 2.5.

Champs

Package	Obsolète. Masque à bits unique représentant package l’accès (accès par défaut), qui peut contribuer au résultat de #lookupModes lookupModes.
Private	Obsolète. Masque à bits unique représentant private l’accès, qui peut contribuer au résultat de #lookupModes lookupModes.
Protected	Obsolète. Masque à bits unique représentant protected l’accès, qui peut contribuer au résultat de #lookupModes lookupModes.
Public	Obsolète. Masque à bits unique représentant public l’accès, qui peut contribuer au résultat de #lookupModes lookupModes.

Propriétés

Class	Retourne la classe runtime de ce Object. (Hérité de Object)
Handle	Handle de l’instance Android sous-jacente. (Hérité de Object)
JniIdentityHashCode	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
JniPeerMembers	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès.
PeerReference	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
ThresholdClass	Cette API prend en charge l’infrastructure Mono pour Android et n’est pas destinée à être utilisée directement à partir de votre code. (Hérité de Object)
ThresholdType	Cette API prend en charge l’infrastructure Mono pour Android et n’est pas destinée à être utilisée directement à partir de votre code. (Hérité de Object)

Méthodes

Bind(Object, String, MethodType)	Produit un handle de méthode à liaison anticipée pour une méthode non statique.
Clone()	Crée et retourne une copie de cet objet. (Hérité de Object)
Dispose()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
Dispose(Boolean)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
Equals(Object)	Indique si un autre objet est « égal à » celui-ci. (Hérité de Object)
FindConstructor(Class, MethodType)	Produit un handle de méthode qui crée un objet et l’initialise à l’aide du constructeur du type spécifié.
FindGetter(Class, String, Class)	Produit un handle de méthode donnant accès en lecture à un champ non statique.
FindSetter(Class, String, Class)	Produit un handle de méthode donnant l’accès en écriture à un champ non statique.
FindSpecial(Class, String, MethodType, Class)	Produit un handle de méthode à liaison anticipée pour une méthode virtuelle.
FindStatic(Class, String, MethodType)	Produit un handle de méthode pour une méthode statique.
FindStaticGetter(Class, String, Class)	Produit un handle de méthode donnant accès en lecture à un champ statique.
FindStaticSetter(Class, String, Class)	Produit un handle de méthode donnant un accès en écriture à un champ statique.
FindStaticVarHandle(Class, String, Class)	Produit un VarHandle donnant accès à un champ name statique de type type déclaré dans une classe de type decl.
FindVarHandle(Class, String, Class)	Produit un VarHandle donnant accès à un champ name non statique de type type déclaré dans une classe de type recv.
FindVirtual(Class, String, MethodType)	Produit un handle de méthode pour une méthode virtuelle.
GetHashCode()	Retourne une valeur de code de hachage pour l'objet. (Hérité de Object)
In(Class)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès.
JavaFinalize()	Appelé par le garbage collector sur un objet lorsque le garbage collection détermine qu’il n’y a plus de références à l’objet. (Hérité de Object)
LookupClass()	Indique à quelle classe effectue la recherche.
LookupModes()	Indique les classes de protection d’accès des membres que cet objet de recherche peut produire.
Notify()	Réveille un thread unique qui attend le moniteur de cet objet. (Hérité de Object)
NotifyAll()	Réveille tous les threads qui attendent le moniteur de cet objet. (Hérité de Object)
RevealDirect(MethodHandle)	Fissure un handle de méthode directe créé par cet objet de recherche ou un handle de méthode similaire.
SetHandle(IntPtr, JniHandleOwnership)	Définit la propriété Handle. (Hérité de Object)
ToArray<T>()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
ToString()	Retourne une représentation de chaîne de l'objet. (Hérité de Object)
Unreflect(Method)	Rend un handle de méthode directe à m, si la classe de recherche a l’autorisation.
UnreflectConstructor(Constructor)	Produit un handle de méthode pour un constructeur réfléchi.
UnreflectGetter(Field)	Produit un handle de méthode donnant accès en lecture à un champ réfléchi.
UnreflectSetter(Field)	Produit un handle de méthode donnant l’accès en écriture à un champ réfléchi.
UnreflectSpecial(Method, Class)	Produit un handle de méthode pour une méthode réfléchie.
UnreflectVarHandle(Field)	Produit un VarHandle donnant accès à un champ f de type T réfléchi déclaré dans une classe de type R.
UnregisterFromRuntime()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
Wait()	Provoque l’attente du thread actuel jusqu’à ce qu’il soit réveillé, généralement en étant <averti par em ou> <em>interrompu</em>.<> (Hérité de Object)
Wait(Int64, Int32)	Provoque l’attente du thread actuel jusqu’à ce qu’il soit réveillé, généralement en étant <averti< par> em>ou <em>interrompu/em>,< ou jusqu’à ce qu’une certaine quantité de temps réel s’est écoulée. (Hérité de Object)
Wait(Int64)	Provoque l’attente du thread actuel jusqu’à ce qu’il soit réveillé, généralement en étant <averti< par> em>ou <em>interrompu/em>,< ou jusqu’à ce qu’une certaine quantité de temps réel s’est écoulée. (Hérité de Object)

Implémentations d’interfaces explicites

IJavaPeerable.Disposed()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.DisposeUnlessReferenced()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.Finalized()	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.JniManagedPeerState	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.SetJniIdentityHashCode(Int32)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.SetJniManagedPeerState(JniManagedPeerStates)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)
IJavaPeerable.SetPeerReference(JniObjectReference)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès. (Hérité de Object)

Méthodes d’extension

JavaCast<TResult>(IJavaObject)	Effectue une conversion de type vérifiée par le runtime Android.
JavaCast<TResult>(IJavaObject)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès.
GetJniTypeName(IJavaPeerable)	Un <objet< de recherche em>> est une fabrique de handles de méthode lors de la création d’un contrôle d’accès.