Virtual extension methods -- a strawman design

Rémi Forax forax at
Sat May 15 11:07:33 PDT 2010

Le 15/05/2010 19:34, Brian Goetz a écrit :
>> A compiler only approach will not work because
>> introducing a new method in an interface breaks the *binary*
>> compatibility.
>> like Neal, I am in favor of a VM only approach.
> As you correctly point out, the choices are VM-only and VM+compiler, and
> compiler-only is not an option.  I see pros and cons for both options.  The
> VM+compiler option is obviously more work for us, but seems likely to reduce
> the impact on the tools ecosystem.  Ignoring the "which is more work" aspect,
> can you outline what you see as the advantages of the VM-only approach?

The principle reason:
Java do the linking at runtime at least the linking of the method
and not at compile time

The practical reason:
We have to do something at runtime, and doing it at compile time
and runtime will weaken the implementation.
Knowning that the tools that operate on bytecodes must be updated
because other JSRs already require these tools to be updated,
I don't see a reason to choose the VM+compiler option.


More information about the lambda-dev mailing list