Bridge methods in the VM

[Brian Goetz]

> 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.)