JSR 292 defines a minimum set of static information which is provided to a bootstrap method when an invokedynamic instruction is first executed. This information is the calling class, the method name, and the method type descriptor.

Some uses of JSR 292 technology will require additional static parameters to pass at link time. It is not practical to pass these parameters dynamically (mixed with non-static parameters).

The most natural way to fix this is to introduce a constant pool entry type which applies a method handle to an argument (or, with nesting, to multiple arguments).

Example:
  Runnable r = #bar();

  //this could translate to:
  ldc MethodHandle #bar
  ldc Runnable.class
  invokevirtual MethodHandles.asInstance

  //or could use static arguments:
  ldc (Apply (MethodHandle #MethodHandles.asInstance)
        (MethodHandle #bar) (Class Runnable))

In the case of a mix of static and dynamic arguments, the above "ldc" would be replaced by an invokedynamic and/or followed by an invokevirtual, to apply the dynamic arguments to the constant constructed statically.

The current workaround to this limitation builds local private BSMs which contain short code sequences to push the extra constants, and then call an augmented BSM. This workaround causes an explosion of constant pool entries to support the extra BSMs. It will be much cheaper (especially in scarce CP entries) to encode the extra constants in CP entries linked to the CONSTANT_InvokeDynamic entry.