* Every method handle reports its type via the {@link #type type} accessor. * This type descriptor is a {@link java.lang.invoke.MethodType MethodType} object, * whose structure is a series of classes, one of which is * the return type of the method (or {@code void.class} if none). *
* A method handle's type controls the types of invocations it accepts, * and the kinds of transformations that apply to it. *
* A method handle contains a pair of special invoker methods * called {@link #invokeExact invokeExact} and {@link #invoke invoke}. * Both invoker methods provide direct access to the method handle's * underlying method, constructor, field, or other operation, * as modified by transformations of arguments and return values. * Both invokers accept calls which exactly match the method handle's own type. * The plain, inexact invoker also accepts a range of other call types. *
* Method handles are immutable and have no visible state. * Of course, they can be bound to underlying methods or data which exhibit state. * With respect to the Java Memory Model, any method handle will behave * as if all of its (internal) fields are final variables. This means that any method * handle made visible to the application will always be fully formed. * This is true even if the method handle is published through a shared * variable in a data race. *
* Method handles cannot be subclassed by the user. * Implementations may (or may not) create internal subclasses of {@code MethodHandle} * which may be visible via the {@link java.lang.Object#getClass Object.getClass} * operation. The programmer should not draw conclusions about a method handle * from its specific class, as the method handle class hierarchy (if any) * may change from time to time or across implementations from different vendors. * *
* As is usual with virtual methods, source-level calls to {@code invokeExact} * and {@code invoke} compile to an {@code invokevirtual} instruction. * More unusually, the compiler must record the actual argument types, * and may not perform method invocation conversions on the arguments. * Instead, it must push them on the stack according to their own unconverted types. * The method handle object itself is pushed on the stack before the arguments. * The compiler then calls the method handle with a type descriptor which * describes the argument and return types. *
* To issue a complete type descriptor, the compiler must also determine * the return type. This is based on a cast on the method invocation expression, * if there is one, or else {@code Object} if the invocation is an expression * or else {@code void} if the invocation is a statement. * The cast may be to a primitive type (but not {@code void}). *
* As a corner case, an uncasted {@code null} argument is given * a type descriptor of {@code java.lang.Void}. * The ambiguity with the type {@code Void} is harmless, since there are no references of type * {@code Void} except the null reference. * *
* When the {@code invokevirtual} is executed after linking, * the receiving method handle's type is first checked by the JVM * to ensure that it matches the descriptor. * If the type match fails, it means that the method which the * caller is invoking is not present on the individual * method handle being invoked. *
* In the case of {@code invokeExact}, the type descriptor of the invocation * (after resolving symbolic type names) must exactly match the method type * of the receiving method handle. * In the case of plain, inexact {@code invoke}, the resolved type descriptor * must be a valid argument to the receiver's {@link #asType asType} method. * Thus, plain {@code invoke} is more permissive than {@code invokeExact}. *
* After type matching, a call to {@code invokeExact} directly * and immediately invoke the method handle's underlying method * (or other behavior, as the case may be). *
* A call to plain {@code invoke} works the same as a call to * {@code invokeExact}, if the type descriptor specified by the caller * exactly matches the method handle's own type. * If there is a type mismatch, {@code invoke} attempts * to adjust the type of the receiving method handle, * as if by a call to {@link #asType asType}, * to obtain an exactly invokable method handle {@code M2}. * This allows a more powerful negotiation of method type * between caller and callee. *
* (Note: The adjusted method handle {@code M2} is not directly observable, * and implementations are therefore not required to materialize it.) * *
* Thus, a method type mismatch which might show up as a linkage error * in a statically typed program can show up as * a dynamic {@code WrongMethodTypeException} * in a program which uses method handles. *
* Because method types contain "live" {@code Class} objects, * method type matching takes into account both types names and class loaders. * Thus, even if a method handle {@code M} is created in one * class loader {@code L1} and used in another {@code L2}, * method handle calls are type-safe, because the caller's type * descriptor, as resolved in {@code L2}, * is matched against the original callee method's type descriptor, * as resolved in {@code L1}. * The resolution in {@code L1} happens when {@code M} is created * and its type is assigned, while the resolution in {@code L2} happens * when the {@code invokevirtual} instruction is linked. *
* Apart from the checking of type descriptors, * a method handle's capability to call its underlying method is unrestricted. * If a method handle is formed on a non-public method by a class * that has access to that method, the resulting handle can be used * in any place by any caller who receives a reference to it. *
* Unlike with the Core Reflection API, where access is checked every time * a reflective method is invoked, * method handle access checking is performed * when the method handle is created. * In the case of {@code ldc} (see below), access checking is performed as part of linking * the constant pool entry underlying the constant method handle. *
* Thus, handles to non-public methods, or to methods in non-public classes, * should generally be kept secret. * They should not be passed to untrusted code unless their use from * the untrusted code would be harmless. * *
* Like classes and strings, method handles that correspond to accessible * fields, methods, and constructors can also be represented directly * in a class file's constant pool as constants to be loaded by {@code ldc} bytecodes. * A new type of constant pool entry, {@code CONSTANT_MethodHandle}, * refers directly to an associated {@code CONSTANT_Methodref}, * {@code CONSTANT_InterfaceMethodref}, or {@code CONSTANT_Fieldref} * constant pool entry. * (For more details on method handle constants, * see the package summary.) *
* Method handles produced by lookups or constant loads from methods or * constructors with the variable arity modifier bit ({@code 0x0080}) * have a corresponding variable arity, as if they were defined with * the help of {@link #asVarargsCollector asVarargsCollector}. *
* A method reference may refer either to a static or non-static method. * In the non-static case, the method handle type includes an explicit * receiver argument, prepended before any other arguments. * In the method handle's type, the initial receiver argument is typed * according to the class under which the method was initially requested. * (E.g., if a non-static method handle is obtained via {@code ldc}, * the type of the receiver is the class named in the constant pool entry.) *
* When a method handle to a virtual method is invoked, the method is * always looked up in the receiver (that is, the first argument). *
* A non-virtual method handle to a specific virtual method implementation * can also be created. These do not perform virtual lookup based on * receiver type. Such a method handle simulates the effect of * an {@code invokespecial} instruction to the same method. * *
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;
assert(s.equals("nanny"));
// weakly typed invocation (using MHs.invoke)
s = (String) mh.invokeWithArguments("sappy", 'p', 'v');
assert(s.equals("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;
assert(x.equals(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;
assert(x.equals(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
* * In source code, a call to a signature polymorphic method will * compile, regardless of the requested type descriptor. * As usual, the Java compiler emits an {@code invokevirtual} * instruction with the given type descriptor against the named method. * The unusual part is that the type descriptor is derived from * the actual argument and return types, not from the method declaration. *
* When the JVM processes bytecode containing signature polymorphic calls, * it will successfully link any such call, regardless of its type descriptor. * (In order to retain type safety, the JVM will guard such calls with suitable * dynamic type checks, as described elsewhere.) *
* Bytecode generators, including the compiler back end, are required to emit * untransformed type descriptors for these methods. * Tools which determine symbolic linkage are required to accept such * untransformed descriptors, without reporting linkage errors. *
* For the sake of tools (but not as a programming API), the signature polymorphic * methods are marked with a private yet standard annotation, * {@code @java.lang.invoke.MethodHandle.PolymorphicSignature}. * The annotation's retention is {@code RUNTIME}, so that all tools can see it. * *
* The following methods (and no others) are signature polymorphic: *
* A signature polymorphic method will be declared with the following properties: *
* When a call to a signature polymorphic method is compiled, the associated linkage information for * its arguments is not array of {@code Object} (as for other similar varargs methods) * but rather the erasure of the static types of all the arguments. *
* In an argument position of a method invocation on a signature polymorphic method, * a null literal has type {@code java.lang.Void}, unless cast to a reference type. * (Note: This typing rule allows the null type to have its own encoding in linkage information * distinct from other types. *
* The linkage information for the return type is derived from a context-dependent target typing convention. * The return type for a signature polymorphic method invocation is determined as follows: *
* The linkage information for argument and return types is stored in the descriptor for the * compiled (bytecode) call site. As for any invocation instruction, the arguments and return value * will be passed directly on the JVM stack, in accordance with the descriptor, * and without implicit boxing or unboxing. * *
* As a special case, * when the Core Reflection API is used to view the signature polymorphic * methods {@code invokeExact} or plain {@code invoke} in this class, * they appear as ordinary non-polymorphic methods. * Their reflective appearance, as viewed by * {@link java.lang.Class#getDeclaredMethod Class.getDeclaredMethod}, * is unaffected by their special status in this API. * For example, {@link java.lang.reflect.Method#getModifiers Method.getModifiers} * will report exactly those modifier bits required for any similarly * declared method, including in this case {@code native} and {@code varargs} bits. *
* As with any reflected method, these methods (when reflected) may be * invoked via {@link java.lang.reflect.Method#invoke Method.invoke}. * However, such reflective calls do not result in method handle invocations. * Such a call, if passed the required argument * (a single one, of type {@code Object[]}), will ignore the argument and * will throw an {@code UnsupportedOperationException}. *
* Since {@code invokevirtual} instructions can natively * invoke method handles under any type descriptor, this reflective view conflicts * with the normal presentation of these methods via bytecodes. * Thus, these two native methods, when reflectively viewed by * {@code Class.getDeclaredMethod}, may be regarded as placeholders only. *
* In order to obtain an invoker method for a particular type descriptor, * use {@link java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvoker}, * or {@link java.lang.invoke.MethodHandles#invoker MethodHandles.invoker}. * The {@link java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual} * API is also able to return a method handle * to call {@code invokeExact} or plain {@code invoke}, * for any specified type descriptor . * *
* Method handles do not represent * their function-like types in terms of Java parameterized (generic) types, * because there are three mismatches between function-like types and parameterized * Java types. *
* When this method is observed via the Core Reflection API, * it will appear as a single native method, taking an object array and returning an object. * If this native method is invoked directly via * {@link java.lang.reflect.Method#invoke Method.invoke}, via JNI, * or indirectly via {@link java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflect}, * it will throw an {@code UnsupportedOperationException}. * @throws WrongMethodTypeException if the target's type is not identical with the caller's type descriptor * @throws Throwable anything thrown by the underlying method propagates unchanged through the method handle call */ public final native @PolymorphicSignature Object invokeExact(Object... args) throws Throwable; /** * Invokes the method handle, allowing any caller type descriptor, * and optionally performing conversions on arguments and return values. *
* If the call site type descriptor exactly matches this method handle's {@link #type type}, * the call proceeds as if by {@link #invokeExact invokeExact}. *
* Otherwise, the call proceeds as if this method handle were first * adjusted by calling {@link #asType asType} to adjust this method handle * to the required type, and then the call proceeds as if by * {@link #invokeExact invokeExact} on the adjusted method handle. *
* There is no guarantee that the {@code asType} call is actually made. * If the JVM can predict the results of making the call, it may perform * adaptations directly on the caller's arguments, * and call the target method handle according to its own exact type. *
* The type descriptor at the call site of {@code invoke} must * be a valid argument to the receivers {@code asType} method. * In particular, the caller must specify the same argument arity * as the callee's type, * if the callee is not a {@linkplain #asVarargsCollector variable arity collector}. *
* When this method is observed via the Core Reflection API, * it will appear as a single native method, taking an object array and returning an object. * If this native method is invoked directly via * {@link java.lang.reflect.Method#invoke Method.invoke}, via JNI, * or indirectly via {@link java.lang.invoke.MethodHandles.Lookup#unreflect Lookup.unreflect}, * it will throw an {@code UnsupportedOperationException}. * @throws WrongMethodTypeException if the target's type cannot be adjusted to the caller's type descriptor * @throws ClassCastException if the target's type can be adjusted to the caller, but a reference cast fails * @throws Throwable anything thrown by the underlying method propagates unchanged through the method handle call */ public final native @PolymorphicSignature Object invoke(Object... args) throws Throwable; /** * Temporary alias for {@link #invoke}, for backward compatibility with some versions of JSR 292. * On some JVMs, support can be excluded by the flags {@code -XX:+UnlockExperimentalVMOptions -XX:-AllowInvokeGeneric}. * @deprecated Will be removed for JSR 292 Proposed Final Draft. */ public final native @PolymorphicSignature Object invokeGeneric(Object... args) throws Throwable; /** * Performs a varargs invocation, passing the arguments in the given array * to the method handle, as if via an inexact {@link #invoke invoke} from a call site * which mentions only the type {@code Object}, and whose arity is the length * of the argument array. *
* Specifically, execution proceeds as if by the following steps, * although the methods are not guaranteed to be called if the JVM * can predict their effects. *
* Because of the action of the {@code asType} step, the following argument * conversions are applied as necessary: *
* The result returned by the call is boxed if it is a primitive, * or forced to null if the return type is void. *
* This call is equivalent to the following code: *
* MethodHandle invoker = MethodHandles.spreadInvoker(this.type(), 0);
* Object result = invoker.invokeExact(this, arguments);
* * Unlike the signature polymorphic methods {@code invokeExact} and {@code invoke}, * {@code invokeWithArguments} can be accessed normally via the Core Reflection API and JNI. * It can therefore be used as a bridge between native or reflective code and method handles. * * @param arguments the arguments to pass to the target * @return the result returned by the target * @throws ClassCastException if an argument cannot be converted by reference casting * @throws WrongMethodTypeException if the target's type cannot be adjusted to take the given number of {@code Object} arguments * @throws Throwable anything thrown by the target method invocation * @see MethodHandles#spreadInvoker */ public Object invokeWithArguments(Object... arguments) throws Throwable { int argc = arguments == null ? 0 : arguments.length; MethodType type = type(); if (type.parameterCount() != argc) { // simulate invoke return asType(MethodType.genericMethodType(argc)).invokeWithArguments(arguments); } if (argc <= 10) { MethodHandle invoker = type.invokers().generalInvoker(); switch (argc) { case 0: return invoker.invokeExact(this); case 1: return invoker.invokeExact(this, arguments[0]); case 2: return invoker.invokeExact(this, arguments[0], arguments[1]); case 3: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2]); case 4: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3]); case 5: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4]); case 6: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5]); case 7: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5], arguments[6]); case 8: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5], arguments[6], arguments[7]); case 9: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5], arguments[6], arguments[7], arguments[8]); case 10: return invoker.invokeExact(this, arguments[0], arguments[1], arguments[2], arguments[3], arguments[4], arguments[5], arguments[6], arguments[7], arguments[8], arguments[9]); } } // more than ten arguments get boxed in a varargs list: MethodHandle invoker = type.invokers().spreadInvoker(0); return invoker.invokeExact(this, arguments); } /** * Performs a varargs invocation, passing the arguments in the given array * to the method handle, as if via an inexact {@link #invoke invoke} from a call site * which mentions only the type {@code Object}, and whose arity is the length * of the argument array. *
* This method is also equivalent to the following code: *
* {@link #invokeWithArguments(Object...) invokeWithArguments}(arguments.toArray())
* * If the original type and new type are equal, returns {@code this}. *
* This method provides the crucial behavioral difference between * {@link #invokeExact invokeExact} and plain, inexact {@link #invoke invoke}. The two methods * perform the same steps when the caller's type descriptor is identical * with the callee's, but when the types differ, plain {@link #invoke invoke} * also calls {@code asType} (or some internal equivalent) in order * to match up the caller's and callee's types. *
* This method is equivalent to {@link MethodHandles#convertArguments convertArguments}, * except for variable arity method handles produced by {@link #asVarargsCollector asVarargsCollector}. * * @param newType the expected type of the new method handle * @return a method handle which delegates to {@code this} after performing * any necessary argument conversions, and arranges for any * necessary return value conversions * @throws WrongMethodTypeException if the conversion cannot be made * @see MethodHandles#convertArguments */ public MethodHandle asType(MethodType newType) { if (!type.isConvertibleTo(newType)) { throw new WrongMethodTypeException("cannot convert "+this+" to "+newType); } return MethodHandleImpl.convertArguments(this, newType, 1); } /** * Makes an adapter which accepts a trailing array argument * and spreads its elements as positional arguments. * The new method handle adapts, as its target, * the current method handle. The type of the adapter will be * the same as the type of the target, except that the final * {@code arrayLength} parameters of the target's type are replaced * by a single array parameter of type {@code arrayType}. *
* If the array element type differs from any of the corresponding * argument types on the original target, * the original target is adapted to take the array elements directly, * as if by a call to {@link #asType asType}. *
* When called, the adapter replaces a trailing array argument * by the array's elements, each as its own argument to the target. * (The order of the arguments is preserved.) * They are converted pairwise by casting and/or unboxing * to the types of the trailing parameters of the target. * Finally the target is called. * What the target eventually returns is returned unchanged by the adapter. *
* Before calling the target, the adapter verifies that the array * contains exactly enough elements to provide a correct argument count * to the target method handle. * (The array may also be null when zero elements are required.) * @param arrayType usually {@code Object[]}, the type of the array argument from which to extract the spread arguments * @param arrayLength the number of arguments to spread from an incoming array argument * @return a new method handle which spreads its final array argument, * before calling the original method handle * @throws IllegalArgumentException if {@code arrayType} is not an array type * @throws IllegalArgumentException if target does not have at least * {@code arrayLength} parameter types * @throws WrongMethodTypeException if the implied {@code asType} call fails * @see #asCollector */ public MethodHandle asSpreader(Class arrayType, int arrayLength) { Class arrayElement = arrayType.getComponentType(); if (arrayElement == null) throw newIllegalArgumentException("not an array type"); int nargs = type().parameterCount(); if (nargs < arrayLength) throw newIllegalArgumentException("bad spread array length"); return MethodHandleImpl.spreadArguments(this, arrayType, arrayLength); } /** * Makes an adapter which accepts a given number of trailing * positional arguments and collects them into an array argument. * The new method handle adapts, as its target, * the current method handle. The type of the adapter will be * the same as the type of the target, except that a single trailing * parameter (usually of type {@code arrayType}) is replaced by * {@code arrayLength} parameters whose type is element type of {@code arrayType}. *
* If the array type differs from the final argument type on the original target, * the original target is adapted to take the array type directly, * as if by a call to {@link #asType asType}. *
* When called, the adapter replaces its trailing {@code arrayLength} * arguments by a single new array of type {@code arrayType}, whose elements * comprise (in order) the replaced arguments. * Finally the target is called. * What the target eventually returns is returned unchanged by the adapter. *
* (The array may also be a shared constant when {@code arrayLength} is zero.) *
* (Note: The {@code arrayType} is often identical to the last * parameter type of the original target. * It is an explicit argument for symmetry with {@code asSpreader}, and also * to allow the target to use a simple {@code Object} as its last parameter type.) *
* In order to create a collecting adapter which is not restricted to a particular * number of collected arguments, use {@link #asVarargsCollector asVarargsCollector} instead. * @param arrayType often {@code Object[]}, the type of the array argument which will collect the arguments * @param arrayLength the number of arguments to collect into a new array argument * @return a new method handle which collects some trailing argument * into an array, before calling the original method handle * @throws IllegalArgumentException if {@code arrayType} is not an array type * or {@code arrayType} is not assignable to this method handle's trailing parameter type, * or {@code arrayLength} is not a legal array size * @throws WrongMethodTypeException if the implied {@code asType} call fails * @see #asSpreader * @see #asVarargsCollector */ public MethodHandle asCollector(Class arrayType, int arrayLength) { asCollectorChecks(arrayType, arrayLength); MethodHandle collector = ValueConversions.varargsArray(arrayType, arrayLength); return MethodHandleImpl.collectArguments(this, type.parameterCount()-1, collector); } private void asCollectorChecks(Class arrayType, int arrayLength) { Class arrayElement = arrayType.getComponentType(); if (arrayElement == null) throw newIllegalArgumentException("not an array type", arrayType); int nargs = type().parameterCount(); if (nargs == 0 || !type().parameterType(nargs-1).isAssignableFrom(arrayType)) throw newIllegalArgumentException("array type not assignable to trailing argument", this, arrayType); } /** * Makes a variable arity adapter which is able to accept * any number of trailing positional arguments and collect them * into an array argument. *
* The type and behavior of the adapter will be the same as * the type and behavior of the target, except that certain * {@code invoke} and {@code asType} requests can lead to * trailing positional arguments being collected into target's * trailing parameter. * Also, the last parameter type of the adapter will be * {@code arrayType}, even if the target has a different * last parameter type. *
* When called with {@link #invokeExact invokeExact}, the adapter invokes * the target with no argument changes. * (Note: This behavior is different from a * {@linkplain #asCollector fixed arity collector}, * since it accepts a whole array of indeterminate length, * rather than a fixed number of arguments.) *
* When called with plain, inexact {@link #invoke invoke}, if the caller * type is the same as the adapter, the adapter invokes the target as with * {@code invokeExact}. * (This is the normal behavior for {@code invoke} when types match.) *
* Otherwise, if the caller and adapter arity are the same, and the * trailing parameter type of the caller is a reference type identical to * or assignable to the trailing parameter type of the adapter, * the arguments and return values are converted pairwise, * as if by {@link MethodHandles#convertArguments convertArguments}. * (This is also normal behavior for {@code invoke} in such a case.) *
* Otherwise, the arities differ, or the adapter's trailing parameter * type is not assignable from the corresponding caller type. * In this case, the adapter replaces all trailing arguments from * the original trailing argument position onward, by * a new array of type {@code arrayType}, whose elements * comprise (in order) the replaced arguments. *
* The caller type must provides as least enough arguments, * and of the correct type, to satisfy the target's requirement for * positional arguments before the trailing array argument. * Thus, the caller must supply, at a minimum, {@code N-1} arguments, * where {@code N} is the arity of the target. * Also, there must exist conversions from the incoming arguments * to the target's arguments. * As with other uses of plain {@code invoke}, if these basic * requirements are not fulfilled, a {@code WrongMethodTypeException} * may be thrown. *
* In all cases, what the target eventually returns is returned unchanged by the adapter. *
* In the final case, it is exactly as if the target method handle were * temporarily adapted with a {@linkplain #asCollector fixed arity collector} * to the arity required by the caller type. * (As with {@code asCollector}, if the array length is zero, * a shared constant may be used instead of a new array. * If the implied call to {@code asCollector} would throw * an {@code IllegalArgumentException} or {@code WrongMethodTypeException}, * the call to the variable arity adapter must throw * {@code WrongMethodTypeException}.) *
* The behavior of {@link #asType asType} is also specialized for * variable arity adapters, to maintain the invariant that * plain, inexact {@code invoke} is always equivalent to an {@code asType} * call to adjust the target type, followed by {@code invokeExact}. * Therefore, a variable arity adapter responds * to an {@code asType} request by building a fixed arity collector, * if and only if the adapter and requested type differ either * in arity or trailing argument type. * The resulting fixed arity collector has its type further adjusted * (if necessary) to the requested type by pairwise conversion, * as if by another application of {@code asType}. *
* When a method handle is obtained by executing an {@code ldc} instruction * of a {@code CONSTANT_MethodHandle} constant, and the target method is marked * as a variable arity method (with the modifier bit {@code 0x0080}), * the method handle will accept multiple arities, as if the method handle * constant were created by means of a call to {@code asVarargsCollector}. *
* In order to create a collecting adapter which collects a predetermined * number of arguments, and whose type reflects this predetermined number, * use {@link #asCollector asCollector} instead. *
* No method handle transformations produce new method handles with * variable arity, unless they are documented as doing so. * Therefore, besides {@code asVarargsCollector}, * all methods in {@code MethodHandle} and {@code MethodHandles} * will return a method handle with fixed arity, * except in the cases where they are specified to return their original * operand (e.g., {@code asType} of the method handle's own type). *
* Calling {@code asVarargsCollector} on a method handle which is already * of variable arity will produce a method handle with the same type and behavior. * It may (or may not) return the original variable arity method handle. *
* Here is an example, of a list-making variable arity method handle: *
MethodHandle asList = publicLookup()
.findStatic(Arrays.class, "asList", methodType(List.class, Object[].class))
.asVarargsCollector(Object[].class);
assertEquals("[]", asList.invoke().toString());
assertEquals("[1]", asList.invoke(1).toString());
assertEquals("[two, too]", asList.invoke("two", "too").toString());
Object[] argv = { "three", "thee", "tee" };
assertEquals("[three, thee, tee]", asList.invoke(argv).toString());
List ls = (List) asList.invoke((Object)argv);
assertEquals(1, ls.size());
assertEquals("[three, thee, tee]", Arrays.toString((Object[])ls.get(0)));
* * Discussion: * These rules are designed as a dynamically-typed variation * of the Java rules for variable arity methods. * In both cases, callers to a variable arity method or method handle * can either pass zero or more positional arguments, or else pass * pre-collected arrays of any length. Users should be aware of the * special role of the final argument, and of the effect of a * type match on that final argument, which determines whether * or not a single trailing argument is interpreted as a whole * array or a single element of an array to be collected. * Note that the dynamic type of the trailing argument has no * effect on this decision, only a comparison between the static * type descriptor of the call site and the type of the method handle.) *
* As a result of the previously stated rules, the variable arity behavior * of a method handle may be suppressed, by binding it to the exact invoker * of its own type, as follows: *
MethodHandle vamh = publicLookup()
.findStatic(Arrays.class, "asList", methodType(List.class, Object[].class))
.asVarargsCollector(Object[].class);
MethodHandle mh = MethodHandles.exactInvoker(vamh.type()).bindTo(vamh);
assert(vamh.type().equals(mh.type()));
assertEquals("[1, 2, 3]", vamh.invoke(1,2,3).toString());
boolean failed = false;
try { mh.invoke(1,2,3); }
catch (WrongMethodTypeException ex) { failed = true; }
assert(failed);
* * When called, the bound handle inserts the given value {@code x} * as a new leading argument to the target. The other arguments are * also passed unchanged. * What the target eventually returns is returned unchanged by the bound handle. *
* The reference {@code x} must be convertible to the first parameter * type of the target. *
* (Note: Because method handles are immutable, the target method handle * retains its original type and behavior.) * @param x the value to bind to the first argument of the target * @return a new method handle which prepends the given value to the incoming * argument list, before calling the original method handle * @throws IllegalArgumentException if the target does not have a * leading parameter type that is a reference type * @throws ClassCastException if {@code x} cannot be converted * to the leading parameter type of the target * @see MethodHandles#insertArguments */ public MethodHandle bindTo(Object x) { Class ptype; if (type().parameterCount() == 0 || (ptype = type().parameterType(0)).isPrimitive()) throw newIllegalArgumentException("no leading reference parameter", x); x = MethodHandles.checkValue(ptype, x); // Cf. MethodHandles.insertArguments for the following logic: MethodHandle bmh = MethodHandleImpl.bindReceiver(this, x); if (bmh != null) return bmh; return MethodHandleImpl.bindArgument(this, 0, x); } /** * Returns a string representation of the method handle, * starting with the string {@code "MethodHandle"} and * ending with the string representation of the method handle's type. * In other words, this method returns a string equal to the value of: *
* "MethodHandle" + type().toString()
* * (Note: Future releases of this API may add further information * to the string representation. * Therefore, the present syntax should not be parsed by applications.) * * @return a string representation of the method handle */ @Override public String toString() { return getNameString(this); } }