RI update: division of bridging responsibility between VM and compiler

Brian Goetz brian.goetz at oracle.com
Thu May 9 11:31:36 PDT 2013


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




More information about the lambda-spec-experts mailing list