RI update: division of bridging responsibility between VM and compiler

[Brian Goetz]

> I have a question, do we have an idea of the bridge methods that need to
> be included in java.util classes becaue we have added default methods on
> several interfaces ?

We don't, but we should be able to measure that pretty easily -- write 
an ASM program to crawl the JDK and emit a diagnostic for every 
ACC_BRIDGE method it finds.

> As I currently understand the problem, I don't think there will be much
> trouble for code that use the JDK.
> But for code like Guava collection that uses JDK interfaces and are used
> in application code, it will be more complex.
> That said I don't know if Guava introduces new interfaces that use
> covariant return type or bounded generics.

Constructs like:

   interface FooPredicate extends Predicate<Foo> { ... }

seem likely enough in third party libraries.  In this case, javac would 
generate the bridge into FooPredicate at compile time.

>> Instead, we're now pursuing a path where we generate bridges into
>> interfaces (since we can do that now) using an algorithm very similar
>> to what we do with class bridges.  We may need to extend the technique
>> of compiler-generated bridges with generating additional classfile
>> attributes that the VM might act on to avoid these anomalies,
>> currently being explored.
>
> I don't understand the last sentence ?
> The bridges are needed by the VM, so what's the point of having the VM
> ignore them ?

The fundamental problem that bridges address is: the notion of 
inheritance implemented by the Java language and by the JVM are 
different.  What appears to be two methods to the JVM may or may not be 
the "same" method in Java.

Bridges paper over this difference by generating bytecode that the VM 
dumbly interprets.  But if the VM *knew* that method A was a bridge for 
method B, it could do a better job.  For example, imagine a VM 
implementation where the vtable contained MHs.  Instead of building 
bytecode for method A that just does a (potentially virtual) call to 
method B, we could populate the slot for A with B.asType(A).  This could 
peel one layer off the call stack.

The last sentence was appealing to the notion that we could tag the 
bridge method with an attribute that made its semantics scrutable to the 
VM, so the VM could use this information to optimize.  (Think "symlink").

We have no plans to act on this information immediately, but reifying 
information about the difference between language-level inheritance and 
VM-level inheritance seems better than throwing this information away 
and then trying to reconstruct it.