RI update: division of bridging responsibility between VM and compiler

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu May 9 13:56:48 PDT 2013

With latest compiler I get this:

interface A {
    Object m();

interface B extends A {
     Integer m();

javap output:

   public abstract java.lang.Integer m();
     descriptor: ()Ljava/lang/Integer;

   public java.lang.Object m();
     descriptor: ()Ljava/lang/Object;
       stack=1, locals=1, args_size=1
          0: aload_0
          1: invokeinterface #1,  1            // InterfaceMethod 
          6: areturn
         line 5: 0

Since the bridging logic is being reused it seems strange that javac is 
generating bridges without the ACC_BRIDGE flag. Could you post an 
example where this is not the case?


On 09/05/13 19:31, Brian Goetz wrote:
>>>> 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.
> No, the user should have no need to recompile in this case.  If the 
> compiler detects that the interface to which a lambda is being 
> converted lacks the needed bridges, it takes corrective action in the 
> translation process, to ensure the needed bridges are injected.
>> I've also found that javac of b88 doesn't mark bridge in interface as
>> 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
> I'll log this as a bug, thanks.

More information about the lambda-spec-experts mailing list