I'm worry that we are missing the big picture here, bridging by the VM
is one way to patch the vtable, there is another feature we need which
is also equivalent to paching the vtable, the where condition, the
method specialization where a generic method is replaced by a specific
version depending on the value of the type arguments.
We're not missing that picture; we're just separating the two issues.
But, bridging is _not_ just about patching the vtable. As outlined
here, it is about _redirecting_ before selection time.
Compiler-generated bridges can only operate at selection time;
forwarding bridges can also operate at resolution time, eliminating the
problem of "stale" bridging code (and enabling bridging for fields.)
Note that if instead of a forwardeeType being a descriptor, we use a
constant method handle, we have the semantics of the lambda
metafactory when there is no captured values.
Right, but that only handles the part where you actually want to invoke
the bridge. It doesn't address the resolution-time option of not
calling that method _at all_, but instead calling a different method.
(Method handles already have their invocation mode built in.)
