The specification for MethodHandle guarantees that each method handle has a method called invokeExact (and also invoke):
 * A method handle contains a pair of special invoker methods
 * called {@link #invokeExact invokeExact} and {@link #invoke invoke}.

Because of JVM limits on the arity of methods, any non-static method can take at most 254 arguments, for total argument count (including receiver) of 255.  The limit is lower if there are doubles or longs.

Therefore, a method handle's invokeExact method, and hence its type, cannot have an arity larger than 254.

It is therefore impossible to:

* lookup (reify as a method handle) a static method with arity 255
* lookup (reify as a method handle) a non-static method or constructor with arity 254
* create a dropArguments or permuteArguments transform which increases the resulting arity to 255 or more
* create a collector transform which collects zero arguments and increases the resulting arity to 255 or more
* request an asType or explicitCastArguments conversion of a method handle to a type of arity 255
* create an exactInvoker or generic invoker for method handles with arity 254
* create a spreadInvoker for method handles with arity 254 which spreads less than two arguments

All of these attempts throw (or should throw) IllegalArgumentException.

The mentioned limits decrease if longs or doubles are present, because longs or doubles count (relative to the JVM limit of 255) as two argument slots.

For example, since MethodHandles.exactInvoker produces a method handle which invokes its first argument, it follows that the exact invoker's argument can have an arity of no more than 253. I.e., you cannot make an exactInvoker (or generic invoker) for a method handle type with a maximal arity of 254.

It is theoretically possible to delay the throw by creating a "dummy" MH that refuses its inputs, but the 292 API generally has a fail-fast design in such corner cases.  For example, an asType that requests an impossible conversion will throw WrongMethodTypeException, rather than deferring to a later invocation of the broken method handle.

The preceding points are not changes to the original JSR 292 specification, but rather necessary implications of that specification, when combined with the basic limitation of JVM methods to receive at most 255 arguments.  Therefore, this bug calls for an editorial change to the javadoc, rather than a change to the specification.  It may suggest additional compliance tests, but does not require or allow behavior inconsistent with the original specification.