RI update: division of bridging responsibility between VM and compiler

[Remi Forax]

On 05/09/2013 05:56 PM, Brian Goetz wrote:
>> I more worry about existing third party libraries that uses already
>> existing interfaces like List or Map
>> because these libraries may need to be re-compiled.
>> I agree that they need to be recompiled only in a corner case,
>> the third party library need to extends an already existing interface
>> and have a public method
>> with a name and parameter types that make the method an override of a
>> default method listed below,
>> but this corner case will appear.
>
> OK, but bear in mind that this is a problem we've had since Java 5, 
> when the abomination that is bridges was deemed to be a good idea.  
> We're not creating new problems here, and the existing problems have 
> not turned out to be big problems in practice. (We've been in 
> "recompile your code" mode since Java 5, but the number of times 
> people have actually had to is quite small, small enough to make us 
> all believe we're not actually in that mode.)
>
>> By example, a comparator defined like this will cause trouble:
>> public class FooComparator extends Comparator<Foo> {
>>    public FooComparator reverseOrder() { ... }
>> }
>>
>> this code must be be recompiled because javac need to insert a bridge.
>
> Try it with the lambda compiler!  We guard against this case, and it 
> works fine.  Decompile the code to find out how :)
>

??,
the point is that users will need to recompile, and also currently this 
code works with b88
because the code that implement bridges in the VM is still present.

I've also found that javac of b88 doesn't mark bridge in interface as 
BRIDGE,
but current version of javac mark bridge as BRIDGE so I will wait b89
to see if bridges in interfaces are generated in the jdk

Rémi