MethodHandles.Lookup クラス

定義

[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

継承

Object

JavaObject

Object

MethodHandles.Lookup

属性

RegisterAttribute

注釈

<em>lookup オブジェクト</em>は、アクセス チェックが必要な場合にメソッド ハンドルを作成するためのファクトリです。 メソッド ハンドルは、呼び出されたときにアクセス チェックを実行するのではなく、作成時に実行します。 そのため、メソッド ハンドルの作成時に、メソッド ハンドルのアクセス制限を適用する必要があります。 これらの制限が適用される呼び出し元クラスは、#lookupClass 参照クラスと呼ばれます。

メソッド ハンドルを作成する必要があるルックアップ クラスは、それ自体のファクトリを作成するために #lookup MethodHandles.lookup を呼び出します。 Lookup ファクトリ オブジェクトが作成されると、参照クラスの ID が決定され、Lookup オブジェクトに安全に格納されます。 その後、参照クラス (またはそのデリゲート) は、 Lookup オブジェクトのファクトリ メソッドを使用して、アクセスチェックされたメンバーのメソッド ハンドルを作成できます。 これには、参照クラスに許可されているすべてのメソッド、コンストラクター、フィールドが含まれます。プライベートクラスも含まれます。

<h1>"lookups">Lookup Factory メソッド</h1>Lookup オブジェクトのファクトリ メソッドは、メソッド、コンストラクター、フィールドのすべての主要なユース ケースに対応します。 ファクトリ メソッドによって作成される各メソッド ハンドルは、特定の <em>bytecode 動作</em>と同等の機能です。 (バイトコードの動作については、Java仮想マシンの仕様のセクション 5.4.3.5 で説明されています)。これらのファクトリ メソッドと結果のメソッドが処理する動作の概要を次に示します。<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>(T) this.f;</td></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;</td></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#findSetter lookup.findSetter(C.class,"f",FT.class)</td><ttd>FT f;</td><td>this.f = x;</td></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#findStaticSetter lookup.findStaticSetter(C.class,"f",FT.class)</td><td>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><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></tr><tr><td>java.lang.invoke.MethodHandles.Lookup#findSpecial lookup.findSpecial(C.class,"m",MT,this.class)</td><td>T m(A*);</td><td>(T) super.m(arg*);</td></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><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>C(A*);</td><td>(C) aConstructor.newInstance(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></table>

ここでは、 C 型は、メンバーを検索するクラスまたはインターフェイスであり、ルックアップ メソッドで refc という名前のパラメーターとして文書化されています。 メソッド型 MT は、戻り値の型 T と引数の型のシーケンス A*から構成されます。 コンストラクターには、 A* 引数型のシーケンスもあり、 C型の新しく作成されたオブジェクトを返すものと見なされます。 MTとフィールド型FTの両方が、typeという名前のパラメーターとして文書化されています。 仮パラメーター this は、 C型の自己参照を表します。存在する場合は、常にメソッド ハンドル呼び出しの先頭の引数です。 (一部の protected メンバーの場合、 this の型が参照クラスに制限される場合があります。以下を参照してください)。 arg 名前は、他のすべてのメソッド ハンドル引数を表します。 Core Reflection API のコード例では、 thisOrNull 名前は、アクセスされたメソッドまたはフィールドが静的な場合は null 参照を表し、それ以外の場合は this 。 名前 aMethod、 aField、および aConstructor は、指定されたメンバーに対応する反射オブジェクトを表します。

指定されたメンバーが変数アリティ (つまり、メソッドまたはコンストラクター) である場合、返されるメソッド ハンドルも MethodHandle#asVarargsCollector 変数アリティになります。 それ以外の場合は、返されるメソッド ハンドルは固定アリティになります。

<em>Discussion:</em> 検索されるメソッド ハンドルと基になるクラス メンバーとバイトコードの動作の等価性は、いくつかの方法で分解される可能性があります。<ul style="font-size:smaller;"><li>参照クラスのローダーからCにシンボリックにアクセスできない場合でも、同等のJava式またはバイトコード定数がない場合でも、ルックアップは成功します。 <li>同様に、 T または MT が参照クラスのローダーからシンボリックにアクセスできない場合でも、検索は成功します。 たとえば、要求された種類に関係なく、 MethodHandle.invokeExact と MethodHandle.invoke の検索は常に成功します。 <li>セキュリティ マネージャーがインストールされている場合は、さまざまな理由で参照を禁止できます (下記参照)。 これに対し、ldc定数に対するCONSTANT_MethodHandle命令は、セキュリティ マネージャーのチェックの対象になりません。 <li>検索メソッドのアリティが非常に大きい場合、メソッド ハンドルの型にパラメーターが多すぎるため、メソッド ハンドルの作成が失敗する可能性があります。 </ul>

<h1>"access">Access チェック</h1> アクセス チェックは、メソッド ハンドルが作成されるときに、 Lookupのファクトリ メソッドに適用されます。 java.lang.reflect.Method#invoke java.lang.reflect.Method.invokeは呼び出しごとにすべての呼び出し元に対してアクセス チェックを実行するため、これは Core Reflection API との主な違いです。

すべてのアクセス チェックは、 Lookup オブジェクトから開始されます。このオブジェクトは、記録された参照クラスを、メソッド ハンドルを作成するすべての要求と比較します。 1 つの Lookup オブジェクトを使用して、任意の数のアクセス チェック メソッド ハンドルを作成し、すべて 1 つの参照クラスに対してチェックできます。

Lookup オブジェクトは、メタオブジェクト プロトコルなどの他の信頼されたコードと共有できます。 共有 Lookup オブジェクトは、ルックアップ クラスのプライベート メンバーに対してメソッド ハンドルを作成する機能を委任します。 特権コードが Lookup オブジェクトを使用している場合でも、アクセス チェックは元の参照クラスの特権に限定されます。

参照が失敗する可能性がある理由は、含むクラスが参照クラスにアクセスできない、または目的のクラス メンバーが見つからない、または必要なクラス メンバーが参照クラスにアクセスできない、または参照オブジェクトがメンバーにアクセスするのに十分な信頼されていないためです。 いずれの場合も、試行された検索から ReflectiveOperationException がスローされます。 正確なクラスは次のいずれかになります。 <ul><li>NoSuchMethodException — メソッドが要求されたが、フィールドが要求されていても存在しない場合は <li>NoSuchFieldException — が存在しない場合は <li>IllegalAccessException — メンバーが存在するが、アクセス チェックが失敗した場合 < ul/ul>

一般に、メソッド ハンドルがメソッドの M を検索できる条件は、参照クラスが Mの呼び出しをコンパイル、検証、解決できる条件以上の制限はありません。 JVM が NoSuchMethodErrorのような例外を発生させる場合、メソッド ハンドルの参照では、通常、 NoSuchMethodExceptionなどの対応するチェックされた例外が発生します。 また、参照によって得られるメソッド ハンドルを呼び出す効果は、コンパイル済み、検証済み、解決済みの Mの呼び出しの実行とまったく同じです。 同じ点は、フィールドとコンストラクターにも当てはまります。

<em>Discussion:</em> Access チェックは、名前付きおよび反映されたメソッド、コンストラクター、およびフィールドにのみ適用されます。 MethodHandle#asType MethodHandle.asTypeなどの他のメソッド ハンドルの作成方法は、アクセス チェックを必要とせず、Lookup オブジェクトとは別に使用されます。

目的のメンバーが protectedされている場合は、通常の JVM 規則が適用されます。これには、ルックアップ クラスが目的のメンバーと同じパッケージに含まれているか、そのメンバーを継承する必要があるという要件が含まれます。 (Java仮想マシンの仕様、セクション 4.9.2、5.4.3.5、および 6.4 を参照してください)。さらに、目的のメンバーが別のパッケージ内の非静的フィールドまたはメソッドである場合、結果のメソッド ハンドルは、参照クラスまたはそのサブクラスの 1 つのオブジェクトにのみ適用できます。 この要件は、先頭の this パラメーターの型を C (必ずしも参照クラスのスーパークラス) から参照クラス自体に絞り込むことで適用されます。

JVM は、 invokespecial 命令にも同様の要件を課します。受信側引数は、解決されたメソッドと現在のクラス <em>and</em> の両方と一致する必要があります。 ここでも、この要件は、先頭のパラメーターの型を結果のメソッド ハンドルに絞り込むことで適用されます。 (Java仮想マシンの仕様、セクション 4.10.1.9 を参照してください)。

JVM は、コンストラクターと静的初期化子ブロックを、特殊な名前 ("<init>" および "<clinit>") を持つ内部メソッドとして表します。 呼び出し命令の内部構文を使用すると、通常のメソッドであるかのようにこのような内部メソッドを参照できますが、JVM バイトコード検証ツールはそれらを拒否します。 このような内部メソッドを検索すると、 NoSuchMethodExceptionが生成されます。

場合によっては、入れ子になったクラス間のアクセスは、同じ最上位宣言内の別のクラスのプライベート メソッドにアクセスするラッパー メソッドを作成することによって、Java コンパイラによって取得されます。 たとえば、入れ子になったクラス C.Dは、C、C.D.E、C.Bなどの他の関連クラス内のプライベート メンバーにアクセスできますが、Java コンパイラでは、関連するクラスでラッパー メソッドを生成する必要がある場合があります。 このような場合、LookupのC.E オブジェクトは、それらのプライベート メンバーに対して実行できません。 この制限の回避策は、 Lookup#in Lookup.in メソッドです。このメソッドは、特別な特権の昇格なしで、 C.E の参照を他のクラスのいずれかに変換できます。

特定の参照オブジェクトに対して許可されるアクセスは、その一連の #lookupModes lookupModesに応じて、通常は参照クラスからアクセスできるメンバーのサブセットに制限される場合があります。 たとえば、 #publicLookup publicLookup メソッドは、パブリック クラスのパブリック メンバーにのみアクセスできる参照オブジェクトを生成します。 呼び出し元の機密性の高いメソッド #lookup lookup は、サポートされているすべてのバイトコード動作をエミュレートするために、呼び出し元クラスに対する完全な機能を持つ参照オブジェクトを生成します。 また、 Lookup#in Lookup.in メソッドでは、元の参照オブジェクトよりもアクセス モードが少ない参照オブジェクトが生成される場合があります。

"privacc"><em>プライベート アクセスの検出:</em> #lookupModes 参照モードにメンバーへの <アクセスの可能性が含まれている場合、ルックアップには>em<private アクセス>/emprivateがあると言います。 他の場所の関連するメソッドに記載されているように、プライベート アクセスを持つルックアップのみが次の機能を持ちます:<ul style="font-size:smaller;"><li>プライベート フィールドにアクセスします。 メソッド、およびルックアップ クラス <li>create メソッドのコンストラクターは、Class.forName<li>create メソッドなどの呼び出し元の機密性の高いメソッドを呼び出すハンドルLookup#findSpecial emulate invokespecialli<avoid パッケージ アクセス チェックで、同じパッケージ メンバー>/ul 内の他のクラスへのプライベート アクセス権を持つルックアップ クラス <li>create Lookup#in delegated lookup objectsにアクセスできるクラスに対する命令liavoid パッケージ アクセス チェックを <処理します。>

これらの各アクセス許可は、プライベート アクセスを持つ参照オブジェクトを、バイトコードの動作とJava言語アクセスのアクセス許可を確実に決定し、メソッド ハンドルによってエミュレートできる元のクラスに安全にトレースできるという事実の結果です。

<h1>"secmgr">Security manager interactions</h1> bytecode 命令は関連するクラス ローダー内のクラスのみを参照できますが、この API は、 Class オブジェクトへの参照が使用可能な限り、任意のクラスのメソッドを検索できます。 このようなクロスローダー参照は Core Reflection API でも可能であり、 invokestatic や getfieldなどの命令をバイトコードすることはできません。 アプリケーションがこのようなクロスローダー参照を確認できるようにする java.lang.SecurityManager セキュリティ マネージャー API があります。 これらのチェックは、 MethodHandles.Lookup API とコア リフレクション API の両方に適用されます ( java.lang.Class Classで確認できます)。

セキュリティ マネージャーが存在する場合、メンバー参照には追加のチェックが適用されます。 セキュリティ マネージャーに対して 1 ~ 3 回の呼び出しが行われます。 これらの呼び出しは、 java.lang.SecurityException SecurityExceptionをスローすることでアクセスを拒否できます。 smgrをセキュリティ マネージャーとして定義し、現在の参照オブジェクトの参照クラスとしてlookcし、メンバーが検索される包含クラスとしてrefcし、メンバーが実際に定義されているクラスとしてdefcします。 現在の参照オブジェクトにプライベート アクセス権がない場合、 lookc 値は <em> 存在しない</em> として定義されます。 呼び出しは、次の規則に従って行われます。 <ul><li><b>Step 1:</b>lookc が存在しない場合、またはそのクラス ローダーが refcのクラス ローダーと同じでも先祖でもない場合は、 SecurityManager#checkPackageAccess smgr.checkPackageAccess(refcPkg) が呼び出されます。ここで、 refcPkg は refcのパッケージです。 <li><b>Step 2:</b> 取得したメンバーがパブリックではなく、lookcが存在しない場合は、SecurityManager#checkPermission smgr.checkPermissionでRuntimePermission("accessDeclaredMembers")が呼び出されます。 <li><b>Step 3:</b> 取得したメンバーがパブリックでない場合、および lookc が存在しない場合、 defc と refc が異なる場合は、 SecurityManager#checkPackageAccess smgr.checkPackageAccess(defcPkg) が呼び出されます。ここで、 defcPkg は defcのパッケージです。 </ul> セキュリティ チェックは、他のアクセス チェックに合格した後に実行されます。 したがって、上記の規則は、パブリックメンバー、またはメンバーにアクセスする権限を持つルックアップ クラスからアクセスされているメンバーを事前に指定します。

<h1>"callsens">Caller sensitive methods</h1>少数のJavaメソッドには、呼び出し元の秘密度と呼ばれる特殊なプロパティがあります。 <em>caller-sensitive</em> メソッドは、直接呼び出し元の ID に応じて動作が異なります。

呼び出し元に依存するメソッドのメソッド ハンドルが要求された場合、バイトコード動作の一般的な規則が適用されますが、参照クラスは特別な方法で考慮されます。 結果のメソッド ハンドルは、参照クラスに含まれる命令から呼び出されたかのように動作し、呼び出し元に依存するメソッドが参照クラスを検出します。 (これに対し、メソッド ハンドルの呼び出し側は無視されます)。したがって、呼び出し元に依存するメソッドの場合、異なるルックアップ クラスによって、動作が異なるメソッド ハンドルが生じる可能性があります。

参照オブジェクトが #publicLookup publicLookup()されている場合、またはプライベート アクセスのない他の参照オブジェクトの場合、参照クラスは無視されます。 このような場合、呼び出し元に依存するメソッド ハンドルを作成できず、アクセスが禁止され、 IllegalAccessExceptionで参照が失敗します。

<em>Discussion:</em> たとえば、呼び出し元に依存するメソッド java.lang.Class#forName(String) Class.forName(x) は、それを呼び出すクラスのクラス ローダーに応じて、さまざまなクラスを返したり、さまざまな例外をスローしたりできます。 バイトコードの動作を判断する適切な方法がないため、 Class.forName のパブリック参照は失敗します。

アプリケーションが広範な共有のためにメソッド ハンドルをキャッシュする場合は、 publicLookup() を使用して作成する必要があります。 Class.forNameの参照がある場合は失敗し、その場合はアプリケーションが適切なアクションを実行する必要があります。 ブートストラップ メソッドの呼び出し中に後で検索を行うと、呼び出し元の特定の ID が組み込まれる可能性があり、メソッドにアクセスできるようになります。

MethodHandles.lookup関数は呼び出し元の機密性が高いので、参照のための安全な基盤を確保できます。 JSR 292 API の他のほぼすべてのメソッドは、参照オブジェクトに依存してアクセス要求を確認します。

Javaドキュメント。

このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。