MethodHandle クラス

定義

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

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

継承

Object

JavaObject

Object

MethodHandle

属性

RegisterAttribute

注釈

メソッド ハンドルは、引数または戻り値の省略可能な変換を使用して、基になるメソッド、コンストラクター、フィールド、または同様の低レベル操作への型指定された直接実行可能な参照です。 これらの変換は非常に一般的であり、#asType 変換、#bindTo 挿入、java.lang.invoke.MethodHandles#dropArguments の削除、java.lang.invoke.MethodHandles#filterArguments の置換などのパターンが含まれます。

<h1>Method ハンドルの内容</h1> メソッド ハンドルは、パラメーターと戻り値の型に従って動的かつ厳密に型指定されます。 これらは、基になるメソッドの名前または定義クラスによって区別されません。 メソッド ハンドルは、メソッド ハンドル独自の #type 型記述子と一致するシンボリック型記述子を使用して呼び出す必要があります。

すべてのメソッド ハンドルは、 #type type アクセサーを介してその型記述子を報告します。 この型記述子は java.lang.invoke.MethodType MethodType オブジェクトであり、その構造体は一連のクラスであり、そのうちの 1 つはメソッドの戻り値の型です (または、存在しない場合は void.class )。

メソッド ハンドルの型は、受け入れる呼び出しの種類と、それに適用される変換の種類を制御します。

メソッド ハンドルには、 #invokeExact invokeExact と #invoke invokeという特殊な呼び出しメソッドのペアが含まれています。 どちらの呼び出し元メソッドも、引数と戻り値の変換によって変更された、メソッド ハンドルの基になるメソッド、コンストラクター、フィールド、またはその他の操作に直接アクセスできます。 どちらの呼び出し元も、メソッド ハンドルの独自の型と完全に一致する呼び出しを受け入れます。 プレーンな inexact 呼び出し側は、他の呼び出しの種類の範囲も受け入れます。

メソッド ハンドルは不変であり、表示状態がありません。 もちろん、それらは、状態を示す基になるメソッドまたはデータにバインドできます。 Javaメモリ モデルに関しては、すべてのメソッド ハンドルは、すべての (内部) フィールドが最終的な変数であるかのように動作します。 つまり、アプリケーションに表示されるメソッド ハンドルは常に完全に形成されます。 これは、データ 競合内の共有変数を介してメソッド ハンドルが発行された場合でも当てはまります。

メソッド ハンドルをユーザーがサブクラス化することはできません。 実装では、 MethodHandle の内部サブクラスが作成される場合と作成されない場合があります。これは、 java.lang.Object#getClass Object.getClass 操作を介して表示される可能性があります。 メソッド ハンドルクラス階層 (ある場合) は、随時、または異なるベンダーからの実装間で変化する可能性があるため、プログラマは特定のクラスからメソッドハンドルに関する結論を導き出すべきではありません。

<h1>Method ハンドル コンパイル</h1> Java メソッド呼び出し式の名前付けinvokeExactまたはinvokeは、ソース コードからメソッド ハンドルJava呼び出すことができます。 ソース コードの観点から、これらのメソッドは任意の引数を受け取ることができ、その結果は任意の戻り値の型にキャストできます。 これは正式には、呼び出し元メソッドに戻り値の型と変数のアリティObject引数Object与えることによって実現されますが、この呼び出しの自由を JVM 実行スタックに直接接続する <em>signature ポリモーフィズム</em>という追加の品質があります。

仮想メソッドの場合と同様に、 invokeExact へのソース レベルの呼び出し invoke 、 invokevirtual 命令にコンパイルされます。 さらに異常に、コンパイラは実際の引数の型を記録する必要があり、引数に対してメソッド呼び出し変換を実行しない可能性があります。 代わりに、独自の変換されていない型に従って、それらをスタックにプッシュする必要があります。 メソッド ハンドル オブジェクト自体は、引数の前にスタックにプッシュされます。 コンパイラは、引数と戻り値の型を記述するシンボリック型記述子を使用してメソッド ハンドルを呼び出します。

完全なシンボリック型記述子を発行するには、コンパイラも戻り値の型を決定する必要があります。 これは、メソッド呼び出し式のキャスト (存在する場合) に基づいています。呼び出しが式の場合は Object 。呼び出しがステートメントの場合は void 。 キャストはプリミティブ型 (ただし、 voidではない) にできます。

コーナー ケースとして、キャストされていない null 引数には、 java.lang.Voidのシンボリック型記述子が指定されます。 Void型のあいまいさは、null 参照を除く型Voidの参照がないため、無害です。

<h1>Method ハンドル呼び出し</h1>invokevirtual 命令が初めて実行されるときは、命令内の名前を記号的に解決し、メソッド呼び出しが静的に有効であることを確認することで、リンクされます。 これは、 invokeExact と invokeの呼び出しに当てはまります。 この場合、コンパイラによって出力されるシンボリック型記述子に正しい構文がチェックされ、それに含まれる名前が解決されます。 したがって、シンボリック型記述子が構文的に整形式であり、型が存在する限り、メソッド ハンドルを呼び出す invokevirtual 命令は常にリンクします。

リンク後に invokevirtual が実行されると、最初に受信側メソッド ハンドルの型が JVM によってチェックされ、シンボリック型記述子と一致することが確認されます。 型の一致が失敗した場合は、呼び出し元が呼び出しているメソッドが、呼び出される個々のメソッド ハンドルに存在しないことを意味します。

invokeExactの場合、呼び出しの型記述子 (シンボリック型名の解決後) は、受信側のメソッド ハンドルのメソッド型と完全に一致する必要があります。 単純な invokeの場合、解決される型記述子は、受信側の #asType asType メソッドに対する有効な引数である必要があります。 したがって、プレーンな invoke は、 invokeExactよりも許容されます。

型の一致後、直接 invokeExact し、メソッド ハンドルの基になるメソッドをすぐに呼び出す呼び出し (場合によってはその他の動作)。

プレーン invoke の呼び出しは、呼び出し元によって指定されたシンボリック型記述子がメソッド ハンドルの独自の型と正確に一致する場合、 invokeExactの呼び出しと同じように動作します。 型の不一致がある場合、 invoke は、 #asType asTypeの呼び出しと同様に、受信メソッド ハンドルの型を調整して、正確に呼び出し可能なメソッド ハンドル M2を取得しようとします。 これにより、呼び出し元と呼び出し先の間のメソッド型のより強力なネゴシエーションが可能になります。

(<em>Note:</em> 調整されたメソッド ハンドルの M2 は直接観察できないため、実装は具体化する必要はありません)。

<h1>Invocation checking</h1> 一般的なプログラムでは、メソッド ハンドルの型の一致は通常成功します。 ただし、一致が失敗した場合、JVM は直接 (WrongMethodTypeExceptionの場合) またはinvokeExactの呼び出しが失敗した場合 (asTypeの場合) と同様に間接的にinvokeをスローします。

したがって、静的に型指定されたプログラムでリンケージ エラーとして表示される可能性があるメソッド型の不一致は、メソッド ハンドルを使用するプログラムの動的な WrongMethodTypeException として表示される可能性があります。

メソッド型には "ライブ" Class オブジェクトが含まれているため、メソッド型の一致では型名とクラス ローダーの両方が考慮されます。 したがって、メソッド ハンドル M が 1 つのクラス ローダー L1 で作成され、別の L2で使用されている場合でも、呼び出し元のシンボリック型記述子は、 L2で解決された呼び出し先メソッドのシンボリック型記述子と照合されるため、メソッド ハンドルの呼び出しは型セーフ L1で解決されます。 L1の解決は、Mが作成され、その種類が割り当てられているときに発生しますが、L2の解決は、invokevirtual命令がリンクされたときに発生します。

型記述子のチェックとは別に、基になるメソッドを呼び出すメソッド ハンドルの機能は無制限です。 メソッド ハンドルが、そのメソッドにアクセスできるクラスによって非パブリック メソッドに形成されている場合、結果のハンドルは、そのメソッドへの参照を受け取る任意の呼び出し元が任意の場所で使用できます。

リフレクション メソッドが呼び出されるたびにアクセスがチェックされる Core Reflection API とは異なり、メソッド ハンドルの作成時にメソッド ハンドルのアクセス チェックが実行されます。 ldcの場合 (下記参照)、定数メソッド ハンドルの基になる定数プール エントリのリンクの一部としてアクセス チェックが実行されます。

したがって、非パブリック メソッドまたは非パブリック クラスのメソッドに対するハンドルは、通常はシークレットにしておく必要があります。 信頼されていないコードからの使用が無害でない限り、信頼されていないコードに渡さないでください。

<h1>Method ハンドルの作成</h1> Java コードは、そのコードにアクセスできる任意のメソッド、コンストラクター、またはフィールドに直接アクセスするメソッド ハンドルを作成できます。 これは、 java.lang.invoke.MethodHandles.Lookup MethodHandles.Lookup と呼ばれる機能ベースの反射型 API を介して行われます。たとえば、静的メソッド ハンドルは、 java.lang.invoke.MethodHandles.Lookup#findStatic Lookup.findStaticから取得できます。 java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflectなど、Core Reflection API オブジェクトからの変換メソッドもあります。

クラスや文字列と同様に、アクセス可能なフィールド、メソッド、コンストラクターに対応するメソッド ハンドルは、クラス ファイルの定数プール内で、 ldc バイトコードによって読み込まれる定数として直接表すこともできます。 新しい種類の定数プール エントリ ( CONSTANT_MethodHandle) は、関連付けられた CONSTANT_Methodref、 CONSTANT_InterfaceMethodref、または定数プール エントリ CONSTANT_Fieldref 直接参照します。 (メソッド ハンドル定数の詳細については、Java仮想マシンの仕様のセクション 4.4.8 と 5.4.3.5 を参照してください)。

変数アリティ修飾子ビット (0x0080) を持つメソッドまたはコンストラクターからの参照または定数読み込みによって生成されるメソッド ハンドルには、 #asVarargsCollector asVarargsCollectorの助けを借りて定義されているかのように、対応する変数アリティがあります。

メソッド参照は、静的メソッドまたは非静的メソッドを参照できます。 非静的な場合、メソッド ハンドル型には、他の引数の前に付加された明示的なレシーバー引数が含まれます。 メソッド ハンドルの型では、最初の受信側引数は、メソッドが最初に要求されたクラスに従って型指定されます。 (たとえば、非静的メソッド ハンドルが ldc を介して取得された場合、受信側の型は定数プール エントリで名前付けされたクラスです)。

メソッド ハンドル定数は、対応するバイトコード命令を同じリンク時アクセス チェックの対象とし、バイトコードの動作でそのようなエラーがスローされる場合、 ldc 命令は対応するリンケージ エラーをスローします。

このため、保護されたメンバーへのアクセスは、アクセスするクラスまたはそのサブクラスの 1 つの受信者のみに制限され、アクセスするクラスは、保護されたメンバーの定義クラスのサブクラス (またはパッケージ兄弟) である必要があります。 メソッド参照が、現在のパッケージの外部にあるクラスの保護された非静的メソッドまたはフィールドを参照する場合、受信側の引数はアクセスするクラスの型に絞り込まれます。

仮想メソッドへのメソッド ハンドルが呼び出されると、メソッドは常に受信側 (つまり、最初の引数) で検索されます。

特定の仮想メソッド実装に対する非仮想メソッド ハンドルも作成できます。 これらは、受信側の種類に基づいて仮想検索を実行しません。 このようなメソッド ハンドルは、同じメソッドに対する invokespecial 命令の効果をシミュレートします。

<h1>使用例</h1> 使用例を次に示します: <blockquote>

{@code
            Object x, y; String s; int i;
            MethodType mt; MethodHandle mh;
            MethodHandles.Lookup lookup = MethodHandles.lookup();
            // mt is (char,char)String
            mt = MethodType.methodType(String.class, char.class, char.class);
            mh = lookup.findVirtual(String.class, "replace", mt);
            s = (String) mh.invokeExact("daddy",'d','n');
            // invokeExact(Ljava/lang/String;CC)Ljava/lang/String;
            assertEquals(s, "nanny");
            // weakly typed invocation (using MHs.invoke)
            s = (String) mh.invokeWithArguments("sappy", 'p', 'v');
            assertEquals(s, "savvy");
            // mt is (Object[])List
            mt = MethodType.methodType(java.util.List.class, Object[].class);
            mh = lookup.findStatic(java.util.Arrays.class, "asList", mt);
            assert(mh.isVarargsCollector());
            x = mh.invoke("one", "two");
            // invoke(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList("one","two"));
            // mt is (Object,Object,Object)Object
            mt = MethodType.genericMethodType(3);
            mh = mh.asType(mt);
            x = mh.invokeExact((Object)1, (Object)2, (Object)3);
            // invokeExact(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
            assertEquals(x, java.util.Arrays.asList(1,2,3));
            // mt is ()int
            mt = MethodType.methodType(int.class);
            mh = lookup.findVirtual(java.util.List.class, "size", mt);
            i = (int) mh.invokeExact(java.util.Arrays.asList(1,2,3));
            // invokeExact(Ljava/util/List;)I
            assert(i == 3);
            mt = MethodType.methodType(void.class, String.class);
            mh = lookup.findVirtual(java.io.PrintStream.class, "println", mt);
            mh.invokeExact(System.out, "Hello, world.");
            // invokeExact(Ljava/io/PrintStream;Ljava/lang/String;)V
            }

</blockquote>invokeExact またはプレーン invoke に対する上記の各呼び出しでは、次のコメントに示されているシンボリック型記述子を使用して、1 つの invokevirtual 命令が生成されます。 これらの例では、ヘルパー メソッド assertEquals は、引数に対して java.util.Objects#equals(Object,Object) Objects.equals を呼び出し、結果が true であることをアサートするメソッドであると見なされます。

<h1>Exceptions</h1> メソッドの invokeExact と invoke は、 java.lang.Throwable Throwableをスローするように宣言されています。つまり、メソッド ハンドルがスローできる静的な制限はありません。 JVMはチェックされた例外とチェックされていない例外を区別しないため(もちろん、クラス以外)、チェックされた例外をメソッドハンドル呼び出しに取り込むのとバイトコード形状に特に影響はありません。 ただし、Javaソース コードでは、メソッド ハンドル呼び出しを実行するメソッドは、明示的にThrowableをスローするか、またはすべてのスロー可能なオブジェクトをローカルでキャッチし、コンテキストで有効なメソッドのみを再スローし、無効なメソッドをラップする必要があります。

<h1>"sigpoly">署名多型</h1>invokeExact とプレーン invoke の通常とは異なるコンパイルとリンケージ動作は、 <em>署名多型</em>という用語によって参照されます。 Java言語仕様で定義されているように、シグネチャポリモーフィック メソッドは、さまざまな呼び出しシグネチャと戻り値の型で動作できるメソッドです。

ソース コードでは、要求されたシンボリック型記述子に関係なく、シグネチャポリモーフィック メソッドの呼び出しがコンパイルされます。 通常どおり、Java コンパイラは、指定されたシンボリック型記述子を持つinvokevirtual命令を、名前付きメソッドに対して出力します。 通常とは異なる部分は、シンボリック型記述子がメソッド宣言からではなく、実際の引数と戻り値の型から派生していることです。

JVM は、署名ポリモーフィック呼び出しを含むバイトコードを処理すると、シンボリック型記述子に関係なく、そのような呼び出しを正常にリンクします。 (タイプ セーフを保持するために、JVM は、他の場所で説明されているように、適切な動的な型チェックを使用してこのような呼び出しを保護します)。

これらのメソッドの変換されていないシンボリック型記述子を出力するには、コンパイラ バックエンドを含むバイトコード ジェネレーターが必要です。 シンボリック・リンケージを決定するツールは、リンケージ・エラーを報告せずに、そのような変換されていない記述子を受け入れる必要があります。

<h1>メソッド ハンドルと Core Reflection API の間の相互運用</h1>java.lang.invoke.MethodHandles.Lookup Lookup API でファクトリ メソッドを使用すると、Core Reflection API オブジェクトで表されるすべてのクラス メンバーを動作と同等のメソッド ハンドルに変換できます。 たとえば、反射 java.lang.reflect.Method Method は、 java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflectを使用してメソッド ハンドルに変換できます。 結果として得られるメソッド ハンドルは、通常、基になるクラス メンバーへのより直接的で効率的なアクセスを提供します。

特殊なケースとして、Core Reflection API を使用して、このクラスのシグネチャポリモーフィック メソッド invokeExact またはプレーン invoke を表示する場合、通常の非ポリモーフィック メソッドとして表示されます。 java.lang.Class#getDeclaredMethod Class.getDeclaredMethodが見た反射的な外観は、この API の特殊な状態の影響を受けません。 たとえば、 java.lang.reflect.Method#getModifiers Method.getModifiers は、同様に宣言されたメソッドに必要な修飾子ビット (この場合は native ビットや varargs ビットなど) を正確に報告します。

反映されたメソッドと同様に、これらのメソッド (反映された場合) は、 java.lang.reflect.Method#invoke java.lang.reflect.Method.invoke経由で呼び出すことができます。 ただし、このような反射呼び出しでは、メソッド ハンドルの呼び出しは発生しません。 このような呼び出しは、必要な引数 ( Object[]型の 1 つの引数) を渡した場合、引数を無視し、 UnsupportedOperationExceptionをスローします。

invokevirtual命令は任意のシンボリック型記述子の下でメソッド ハンドルをネイティブに呼び出すことができるため、この反射ビューはバイトコードを介したこれらのメソッドの通常の表示と競合します。 したがって、これら2つのネイティブメソッドは、 Class.getDeclaredMethodによって反射的に見られる場合、プレースホルダーのみとみなされ得る。

特定の型記述子の呼び出し元メソッドを取得するには、 java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvokerまたは java.lang.invoke.MethodHandles#invoker MethodHandles.invokerを使用します。 java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual API は、指定された型記述子に対して、invokeExactまたはプレーン invokeを呼び出すメソッド ハンドルを返すこともできます。

<h1>メソッド ハンドルと Java ジェネリックの間の相互運用</h1>ジェネリック型で宣言されているメソッド、コンストラクター、またはフィールドでメソッド ハンドルJava取得できます。 Core Reflection API と同様に、メソッド ハンドルの型はソース レベルの型の消去から構築されます。 メソッド ハンドルが呼び出されると、その引数の型または戻り値のキャスト型がジェネリック型または型インスタンスである場合があります。 この場合、コンパイラは、 invokevirtual 命令のシンボリック型記述子を構築するときに、それらの型を消去によって置き換えます。

メソッド ハンドルは、Javaパラメーター化 (ジェネリック) 型の観点から関数に似た型を表しません。これは、関数に似た型とパラメーター化されたJava型の間に 3 つの不一致があるためです。 <ul><li>Method 型は、引数なしから許容される引数の最大数までの範囲で指定できます。 ジェネリックは可変式ではないため、this.< を表すことはできません。/li><li>Method 型はプリミティブ型の引数を指定できます。ジェネリック型Java over.</li><li>メソッド ハンドル (コンバイネーター) に対するHigher オーダー関数は、多くの場合、複数のアリを含むさまざまな関数型にわたってジェネリックです。 このようなジェネリックをJava型パラメーターで表すことはできません。</li></ul>

<h1>"maxarity">Arity limits</h1> JVM は、任意の種類のすべてのメソッドとコンストラクターに対して、255 個の積み上げ引数の絶対制限を適用します。 この制限は、2 つの引数スロットとして <ul><li>A long または double 引数数 (アリティ制限の目的で) など、より制限が厳しい場合があります。 <li>非静的メソッドは、メソッドが呼び出されるオブジェクトに対して追加の引数を使用します。 <li>A コンストラクターは、構築中のオブジェクトに対して追加の引数を使用します。 <li>メソッド ハンドルの実行s invoke メソッド (またはその他のシグネチャポリモーフィック メソッド) は非仮想であり、仮想以外のレシーバー オブジェクトに加えて、メソッド ハンドル自体に対して追加の引数を使用します。 </ul> これらの制限は、スタックされた引数の JVM 制限のため、特定のメソッド ハンドルを作成できないことを意味します。 たとえば、静的 JVM メソッドが 255 個の引数を受け入れる場合、メソッド ハンドルを作成することはできません。 不可能なメソッド型のメソッド ハンドルを作成しようとすると、 IllegalArgumentExceptionが発生します。 特に、メソッド ハンドルs 型には、正確な最大 255 のアリティを含めてはなりません。

Javaドキュメント。

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