This is a straw-man feature for working with value types.
It is entered into JBS in order to attract comments.
It relates to the "minimal values proposal" at
http://cr.openjdk.java.net/~jrose/values/shady-values.html

It should be possible to decide the exact configuration of bridge methods at run-time (when the type hierarchy is finalized). It should also be possible to specify include bridges in class files without the complexity, overhead, and premature specification of stereotyped bytecode bodies for the bridges.

Instead, it should be possible for a bridge method to be declared in a class-file in a form where the Code attribute is missing, but a BootstrapMethod attribute is present. The modifiers would include ACC_BRIDGE + ACC_ABSTRACT (or perhaps ACC_BRIDGE + ACC_NATIVE), signaling that the Code attribute is absent, but the method is in fact going to be concrete.

The BootstrapMethod attribute will carry a 2-byte index into the BootstrapMethods table. The indicated BSM will execute with the following arguments (Lookup, String, MethodType, Object...), where the lookup, name, and string are just as for invokedynamic, but with the indicated method being the bridge method itself. The BootstrapMethod must return a MethodHandle (not a CallSite as for invokedynamic), which, after first resolution of the method from any caller, will be permanently bound to the MethodHandle as its behavior.

This feature may be useful as a more robust and compact replacement for traditional compiler-generated bridge methods.

It may also help with a "war on boilerplate", allowing classes (such as new value-type classes) to encode their equals, hashCode, toString, and compareTo methods using compact, standard "recipes" dynamically expanded by BSMs, instead of redundant and possibly sub-optimal bytecodes, statically generated.

Type wildcarding is a possible add-on: A bridge with a BSM could be marked to allow a range of types (not just the given type descriptor of the bridge). This could provide various degrees of signature-polymorphism, generalizing the special-case of signature-polymorphic MethodHandle and VarHandle methods. The bridge BSM can dynamically refuse a malformed resolution request simply by throwing a LinkageError.

For value types, type wildcarding could allow automatic bridge generation between L-type and Q-type versions of method descriptors.

For methods that use varargs and autoboxing, type wildcarding could allow efficient and secure caller-oriented call sites (which specify unboxed, positional argument sets), and allow the bridge to produce an optimal and safe boxed and variadic array of the incoming arguments. (It is verbose and error-prone to make the caller be responsible for these conversions.)

Name wildcarding is a possible add-on: A bridge with a BSM could be marked to allow a range of names (not just the given name of the bridge). This could provide additional degrees of freedom, allowing name-variants to be linked. Such a thing could implement keyword-based calling sequences, or "last-chance" resolution hooks for missing methods of arbitrary names.