MethodHandles.Lookup Classe

Definição

[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

Herança

Object

JavaObject

Object

MethodHandles.Lookup

Atributos

RegisterAttribute

Comentários

Um <objeto> de pesquisa em</em> é uma fábrica para criar identificadores de método, quando a criação requer verificação de acesso. Os identificadores de método não executam verificações de acesso quando são chamados, mas sim quando são criados. Portanto, as restrições de acesso do identificador de método devem ser impostas quando um identificador de método é criado. A classe de chamador contra a qual essas restrições são impostas é conhecida como a classe de pesquisa #lookupClass.

Uma classe de pesquisa que precisa criar identificadores de método chamará #lookup MethodHandles.lookup para criar uma fábrica para si mesma. Quando o Lookup objeto de fábrica é criado, a identidade da classe de pesquisa é determinada e armazenada com segurança no Lookup objeto. A classe de pesquisa (ou seus delegados) pode usar métodos de fábrica no Lookup objeto para criar identificadores de método para membros verificados pelo acesso. Isso inclui todos os métodos, construtores e campos que têm permissão para a classe de pesquisa, até mesmo os privados.

<h1>"lookups">Métodos de Fábrica< de Pesquisa/h1> Os métodos de fábrica em um Lookup objeto correspondem a todos os casos de uso principais para métodos, construtores e campos. Cada identificador de método criado por um método de fábrica é o equivalente funcional de um <>comportamento</em> bytecode específico. (Comportamentos de bytecode são descritos na seção 5.4.3.5 da especificação da máquina virtual Java.) Aqui está um resumo da correspondência entre esses métodos de fábrica e o comportamento que o método resultante manipula: <table border=1 cellpadding=5 summary="lookup method behaviors"><tr><th>"equiv">lookup expression</th th><>member</th th><>bytecode behavior</th></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#findGetter lookup.findGetter(C.class,"f",FT.class)</td td><>FT f;</td td><td/>(T) this.f;< td/tr><tr><td><>/td tdjava.lang.invoke.MethodHandles.Lookup#findStaticGetter lookup.findStaticGetter(C.class,"f",FT.class)<><>brstatic<>/td tdFT f;<><>/td(T) C.f;</tr><tr><td><>/td tdjava.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class)<><>/td tdFT f;<><>/td/tdthis.f = x;<><></td td><>java.lang.invoke.MethodHandles.Lookup#findStaticSetter lookup.findStaticSetter(C.class,"f",FT.class)<><> brstatic<>/td tdFT f;<><>/tdC.f = arg;</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><tr><td>java.lang.invoke.MethodHandles.Lookup#findStatic lookup.findStatic(C.class,"m",MT)</td td><>static<br>T m(A*);</td td><>(T) C.m(arg*);</td/td></tr><td><>java.lang.invoke.MethodHandles.Lookup#findSpecial lookup.findSpecial(C.class,"m",MT,this.class)</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>new C(arg*);</td></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#unreflectGetter lookup.unreflectGetter(aField)</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><>(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><>(static)?<br>T m(A*);</td><td>(T) aMethod.invoke(thisOrNull, arg*);</td></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#unreflectConstructor lookup.unreflectConstructor(aConstructor)</td/td><td>C(A*);<><>(C) aConstructor.newInstance(arg*);/td</td></tr><tr><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>

Aqui, o tipo C é a classe ou interface que está sendo pesquisada para um membro, documentado como um parâmetro nomeado refc nos métodos de pesquisa. O tipo MT de método é composto do tipo T de retorno e da sequência de tipos A*de argumento. O construtor também tem uma sequência de tipos A* de argumento e é considerado para retornar o objeto recém-criado do tipo C. Ambos MT e o tipo FT de campo são documentados como um parâmetro chamado type. O parâmetro this formal significa a auto-referência do tipo C; se ele estiver presente, ele é sempre o argumento principal para a invocação do identificador de método. (No caso de alguns protected membros, this pode ser restrito no tipo à classe de pesquisa; consulte abaixo.) O nome arg significa todos os outros argumentos de identificador de método. Nos exemplos de código para a API de Reflexão Principal, o nome thisOrNull significa uma referência nula se o método ou campo acessado for estático e this de outra forma. Os nomes aMethode aFieldaConstructor a representação de objetos reflexivos correspondentes aos membros fornecidos.

Nos casos em que o membro fornecido for de aridade variável (ou seja, um método ou construtor), o identificador de método retornado também será de aridade variável MethodHandle#asVarargsCollector. Em todos os outros casos, o identificador de método retornado será de aridade fixa.

<em>Discussão:</em> A equivalência entre identificadores de método procurado e membros de classe subjacentes e comportamentos de bytecode pode ser interrompida de algumas maneiras: <ul style="font-size:smaller; "><li>Se C não estiver simbolicamente acessível do carregador da classe de pesquisa, a pesquisa ainda poderá ser bem-sucedida, mesmo quando não houver nenhuma expressão Java equivalente ou constante codificada por byte. <li>Da mesma forma, se T ou MT não estiver simbolicamente acessível do carregador da classe de pesquisa, a pesquisa ainda poderá ser bem-sucedida. Por exemplo, pesquisa MethodHandle.invokeExact e MethodHandle.invoke sempre terá êxito, independentemente do tipo solicitado. <li>Se houver um gerenciador de segurança instalado, ele poderá proibir a pesquisa por vários motivos (veja abaixo). Por outro lado, a ldc instrução sobre uma CONSTANT_MethodHandle constante não está sujeita a verificações do gerenciador de segurança. <li>Se o método pesquisado tiver uma aridade muito grande, a criação do identificador de método poderá falhar, devido ao tipo de identificador de método ter muitos parâmetros. </ul>

<h1>"access">Verificação< de acesso/h1 Verificações de> acesso são aplicadas nos métodos de fábrica de, quando um identificador de Lookupmétodo é criado. Essa é uma diferença fundamental da API de Reflexão Principal, pois java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke executa a verificação de acesso em cada chamador, em cada chamada.

Todas as verificações de acesso começam a partir de um Lookup objeto, que compara sua classe de pesquisa registrada com todas as solicitações para criar identificadores de método. Um único Lookup objeto pode ser usado para criar qualquer número de identificadores de método verificados pelo acesso, todos verificados em uma única classe de pesquisa.

Um Lookup objeto pode ser compartilhado com outro código confiável, como um protocolo metaobjeto. Um objeto compartilhado Lookup delega a capacidade de criar identificadores de método em membros privados da classe de pesquisa. Mesmo que o código privilegiado use o Lookup objeto, a verificação de acesso será limitada aos privilégios da classe de pesquisa original.

Uma pesquisa pode falhar, porque a classe de contenção não está acessível à classe de pesquisa ou porque o membro de classe desejado está ausente ou porque o membro de classe desejado não está acessível à classe de pesquisa ou porque o objeto de pesquisa não é confiável o suficiente para acessar o membro. Em qualquer um desses casos, um ReflectiveOperationException será gerado da tentativa de pesquisa. A classe exata será uma das seguintes: <ul><li>NoSuchMethodException — se um método for solicitado, mas não existir <li>NoSuchFieldException — se um campo for solicitado, mas não existir <li>IllegalAccessException — se o membro existir, mas uma verificação de acesso falhar </ul>

Em geral, as condições sob as quais um identificador de método pode ser pesquisado para um método M não são mais restritivas do que as condições sob as quais a classe de pesquisa poderia ter compilado, verificado e resolvido uma chamada para M. Em que a JVM geraria exceções como NoSuchMethodError, uma pesquisa de identificador de método geralmente gerará uma exceção marcada correspondente, como NoSuchMethodException. E o efeito de invocar o identificador de método resultante da pesquisa é exatamente equivalente à execução da chamada compilada, verificada e resolvida para M. O mesmo ponto é verdadeiro para campos e construtores.

<em>Discussão:</em Verificações de> acesso se aplicam somente a métodos nomeados e refletidos, construtores e campos. Outros métodos de manipulação de método, como MethodHandle#asType MethodHandle.asType, não exigem verificações de acesso e são usados independentemente de qualquer Lookup objeto.

Se o membro desejado for protected, as regras comuns de JVM se aplicam, incluindo o requisito de que a classe de pesquisa deve estar no mesmo pacote que o membro desejado ou deve herdar esse membro. (Consulte o Java Especificação da Máquina Virtual, seções 4.9.2, 5.4.3.5 e 6.4.) Além disso, se o membro desejado for um campo ou método não estático em um pacote diferente, o identificador de método resultante só poderá ser aplicado a objetos da classe de pesquisa ou de uma de suas subclasses. Esse requisito é imposto restringindo o tipo do parâmetro principal this ( C que necessariamente será uma superclasse da classe de pesquisa) para a própria classe de pesquisa.

A JVM impõe um requisito semelhante na invokespecial instrução de que o argumento receptor deve corresponder tanto ao método <resolvido quanto>< à> classe atual. Novamente, esse requisito é imposto restringindo o tipo do parâmetro principal ao identificador de método resultante. (Consulte a Java Especificação da Máquina Virtual, seção 4.10.1.9.)

O JVM representa construtores e blocos de inicializador estáticos como métodos internos com nomes especiais ("<init>" e "<clinit>"). A sintaxe interna das instruções de invocação permite que eles se refiram a métodos internos como se fossem métodos normais, mas o verificador de código de byte JVM os rejeita. Uma pesquisa desse método interno produzirá um NoSuchMethodException.

Em alguns casos, o acesso entre classes aninhadas é obtido pelo compilador Java criando um método wrapper para acessar um método privado de outra classe na mesma declaração de nível superior. Por exemplo, uma classe C.D aninhada pode acessar membros privados em outras classes relacionadas, como C, C.D.Eou C.B, mas o compilador Java pode precisar gerar métodos wrapper nessas classes relacionadas. Nesses casos, um Lookup objeto ativado C.E não seria capaz desses membros privados. Uma solução alternativa para essa limitação é o Lookup#in Lookup.in método, que pode transformar uma pesquisa em C.E uma em qualquer uma dessas outras classes, sem elevação especial de privilégio.

Os acessos permitidos a um determinado objeto de pesquisa podem ser limitados, de acordo com seu conjunto de #lookupModes lookupModes, a um subconjunto de membros normalmente acessível à classe de pesquisa. Por exemplo, o #publicLookup publicLookup método produz um objeto de pesquisa que só tem permissão para acessar membros públicos em classes públicas. O método #lookup lookup sensível ao chamador produz um objeto de pesquisa com recursos completos em relação à sua classe de chamador, para emular todos os comportamentos de código de byte com suporte. Além disso, o Lookup#in Lookup.in método pode produzir um objeto de pesquisa com menos modos de acesso do que o objeto de pesquisa original.

"privacc"><em>Discussão de acesso privado:</em> Dizemos que uma pesquisa tem <>em acesso< privado/em> se seus modos de pesquisa #lookupModes incluem a possibilidade de acessar private membros. Conforme documentado nos métodos relevantes em outros lugares, somente pesquisas com acesso privado possuem os seguintes recursos: <ul style="font-size:smaller;"><li>acessar campos privados, métodos e construtores da classe <de pesquisa li>criar identificadores de método que invocam métodos sensíveis ao chamador, comoClass.forName< identificadores de método li>create quais Lookup#findSpecial emulate invokespecial instruções li<evitar verificações >de acesso de pacote para classes acessíveis à classe <de pesquisa li>criar Lookup#in delegated lookup objects que têm acesso privado a outras classes dentro do mesmo membro <do pacote /ul>

Cada uma dessas permissões é uma consequência do fato de que um objeto de pesquisa com acesso privado pode ser rastreado com segurança para uma classe de origem, cujos comportamentos de código de byte e permissões de acesso ao idioma Java podem ser determinados e emulados de forma confiável por identificadores de método.

<h1>"secmgr">Interações< do gerenciador de segurança/h1> Embora as instruções de código de byte só possam se referir a classes em um carregador de classe relacionado, essa API pode pesquisar métodos em qualquer classe, desde que uma referência ao objeto Class esteja disponível. Essas referências de carregador cruzado também são possíveis com a API de Reflexão Principal e são impossíveis de codificar instruções como invokestatic ou getfield. Há uma API do gerenciador de segurança java.lang.SecurityManager para permitir que os aplicativos verifiquem essas referências entre carregadores. Essas verificações se aplicam à MethodHandles.Lookup API e à API de Reflexão Central (conforme encontrado).java.lang.Class Class

Se um gerenciador de segurança estiver presente, as pesquisas de membros estarão sujeitas a verificações adicionais. De uma a três chamadas são feitas ao gerente de segurança. Qualquer uma dessas chamadas pode recusar o acesso lançando um java.lang.SecurityException SecurityException. Defina smgr como o gerenciador de segurança, lookc como a classe de pesquisa do objeto de pesquisa atual, refc como a classe de contenção na qual o membro está sendo procurado e defc como a classe na qual o membro é realmente definido. O valor lookc será definido como <em>não presente</em> se o objeto de pesquisa atual não tiver acesso privado. As chamadas são feitas de acordo com as seguintes regras: ul<li b Etapa 1:>/b< Se >< não estiver presente ou se o carregador de classe não for o mesmo que ou um ancestral do carregador de classe de>, em seguida<, é chamado, onde > está o pacote de lookc.refcSecurityManager#checkPackageAccess smgr.checkPackageAccess(refcPkg)refcPkgrefc <li><b>Etapa 2:</b> Se o membro recuperado não for público e lookc não estiver presente, SecurityManager#checkPermission smgr.checkPermission ele RuntimePermission("accessDeclaredMembers") será chamado. <li><b>Etapa 3:</b> Se o membro recuperado não for público e se lookc não estiver presente e se defc e refc forem diferentes, então SecurityManager#checkPackageAccess smgr.checkPackageAccess(defcPkg) será chamado, onde defcPkg está o pacote de defc. </ul> Verificações de segurança são executadas depois que outras verificações de acesso são aprovadas. Portanto, as regras acima presupõem um membro que seja público ou que esteja sendo acessado de uma classe de pesquisa que tenha direitos para acessar o membro.

<h1>"callsens">Métodos< sensíveis ao chamador/h1> Um pequeno número de métodos Java tem uma propriedade especial chamada confidencialidade do chamador. Um <método em>que diferencia o< chamador/em> pode se comportar de forma diferente dependendo da identidade de seu chamador imediato.

Se um identificador de método para um método sensível ao chamador for solicitado, as regras gerais para comportamentos de código de byte se aplicam, mas elas levam em conta a classe de pesquisa de uma maneira especial. O identificador de método resultante se comporta como se fosse chamado de uma instrução contida na classe de pesquisa, de modo que o método sensível ao chamador detecte a classe de pesquisa. (Por outro lado, o invocador do identificador do método é desconsiderado.) Assim, no caso de métodos sensíveis ao chamador, diferentes classes de pesquisa podem dar origem a identificadores de método de comportamento diferente.

Nos casos em que o objeto de pesquisa está #publicLookup publicLookup()ou algum outro objeto de pesquisa sem acesso privado, a classe de pesquisa é desconsiderada. Nesses casos, nenhum identificador de método sensível ao chamador pode ser criado, o acesso é proibido e a pesquisa falha com um IllegalAccessException.

<em>Discussão:</em> Por exemplo, o método java.lang.Class#forName(String) Class.forName(x) sensível ao chamador pode retornar classes variadas ou gerar exceções variadas, dependendo do carregador de classe da classe que o chama. Uma pesquisa Class.forName pública falhará, porque não há uma maneira razoável de determinar seu comportamento de código de byte.

Se um método de cache de aplicativo for manipulado para compartilhamento amplo, ele deverá ser usado publicLookup() para criá-los. Se houver uma pesquisa, Class.forNameela falhará e o aplicativo deverá tomar as medidas apropriadas nesse caso. Pode ser que uma pesquisa posterior, talvez durante a invocação de um método bootstrap, possa incorporar a identidade específica do chamador, tornando o método acessível.

A função MethodHandles.lookup é sensível ao chamador para que possa haver uma base segura para pesquisas. Quase todos os outros métodos na API JSR 292 dependem de objetos de pesquisa para verificar solicitações de acesso.

Java documentação para java.lang.invoke.MethodHandles.Lookup.

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Project Open Source do Open Source e usadas de acordo com os termos descritos na Creative Commons 2.5.