367  * will throw an {@code UnsupportedOperationException}.
 368  * <p>
 369  * Since {@code invokevirtual} instructions can natively
 370  * invoke method handles under any symbolic type descriptor, this reflective view conflicts
 371  * with the normal presentation of these methods via bytecodes.
 372  * Thus, these two native methods, when reflectively viewed by
 373  * {@code Class.getDeclaredMethod}, may be regarded as placeholders only.
 374  * <p>
 375  * In order to obtain an invoker method for a particular type descriptor,
 376  * use {@link java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvoker},
 377  * or {@link java.lang.invoke.MethodHandles#invoker MethodHandles.invoker}.
 378  * The {@link java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual}
 379  * API is also able to return a method handle
 380  * to call {@code invokeExact} or plain {@code invoke},
 381  * for any specified type descriptor .
 382  *
 383  * <h1>Interoperation between method handles and Java generics</h1>
 384  * A method handle can be obtained on a method, constructor, or field
 385  * which is declared with Java generic types.
 386  * As with the Core Reflection API, the type of the method handle
 387  * will constructed from the erasure of the source-level type.
 388  * When a method handle is invoked, the types of its arguments
 389  * or the return value cast type may be generic types or type instances.
 390  * If this occurs, the compiler will replace those
 391  * types by their erasures when it constructs the symbolic type descriptor
 392  * for the {@code invokevirtual} instruction.
 393  * <p>
 394  * Method handles do not represent
 395  * their function-like types in terms of Java parameterized (generic) types,
 396  * because there are three mismatches between function-like types and parameterized
 397  * Java types.
 398  * <ul>
 399  * <li>Method types range over all possible arities,
 400  * from no arguments to up to the  <a href="MethodHandle.html#maxarity">maximum number</a> of allowed arguments.
 401  * Generics are not variadic, and so cannot represent this.</li>
 402  * <li>Method types can specify arguments of primitive types,
 403  * which Java generic types cannot range over.</li>
 404  * <li>Higher order functions over method handles (combinators) are
 405  * often generic across a wide range of function types, including
 406  * those of multiple arities.  It is impossible to represent such
 407  * genericity with a Java type parameter.</li>

 367  * will throw an {@code UnsupportedOperationException}.
 368  * <p>
 369  * Since {@code invokevirtual} instructions can natively
 370  * invoke method handles under any symbolic type descriptor, this reflective view conflicts
 371  * with the normal presentation of these methods via bytecodes.
 372  * Thus, these two native methods, when reflectively viewed by
 373  * {@code Class.getDeclaredMethod}, may be regarded as placeholders only.
 374  * <p>
 375  * In order to obtain an invoker method for a particular type descriptor,
 376  * use {@link java.lang.invoke.MethodHandles#exactInvoker MethodHandles.exactInvoker},
 377  * or {@link java.lang.invoke.MethodHandles#invoker MethodHandles.invoker}.
 378  * The {@link java.lang.invoke.MethodHandles.Lookup#findVirtual Lookup.findVirtual}
 379  * API is also able to return a method handle
 380  * to call {@code invokeExact} or plain {@code invoke},
 381  * for any specified type descriptor .
 382  *
 383  * <h1>Interoperation between method handles and Java generics</h1>
 384  * A method handle can be obtained on a method, constructor, or field
 385  * which is declared with Java generic types.
 386  * As with the Core Reflection API, the type of the method handle
 387  * will be constructed from the erasure of the source-level type.
 388  * When a method handle is invoked, the types of its arguments
 389  * or the return value cast type may be generic types or type instances.
 390  * If this occurs, the compiler will replace those
 391  * types by their erasures when it constructs the symbolic type descriptor
 392  * for the {@code invokevirtual} instruction.
 393  * <p>
 394  * Method handles do not represent
 395  * their function-like types in terms of Java parameterized (generic) types,
 396  * because there are three mismatches between function-like types and parameterized
 397  * Java types.
 398  * <ul>
 399  * <li>Method types range over all possible arities,
 400  * from no arguments to up to the  <a href="MethodHandle.html#maxarity">maximum number</a> of allowed arguments.
 401  * Generics are not variadic, and so cannot represent this.</li>
 402  * <li>Method types can specify arguments of primitive types,
 403  * which Java generic types cannot range over.</li>
 404  * <li>Higher order functions over method handles (combinators) are
 405  * often generic across a wide range of function types, including
 406  * those of multiple arities.  It is impossible to represent such
 407  * genericity with a Java type parameter.</li>