RI update: division of bridging responsibility between VM and compiler

[Maurizio Cimadamore]

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;
     flags: ACC_PUBLIC, ACC_ABSTRACT

   public java.lang.Object m();
     descriptor: ()Ljava/lang/Object;
     flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
     Code:
       stack=1, locals=1, args_size=1
          0: aload_0
          1: invokeinterface #1,  1            // InterfaceMethod 
m:()Ljava/lang/Integer;
          6: areturn
       LineNumberTable:
         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?

Maurizio

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
>> 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
>
> I'll log this as a bug, thanks.
>
>