RI update: division of bridging responsibility between VM and compiler

[Remi Forax]

On 05/09/2013 10:56 PM, Maurizio Cimadamore wrote:
> 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

There is no bug, it's just that the version used by jdk8b88 doesn't mark 
bridge as ACC_BRIDGE,
as you say newer version does.
My first question was does the jdk has bridge in interfaces somewhere,
but because I've only tested with b88, I can not answer to that question.
I will wait b89 for that.

Rémi


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