Virtual extension methods -- a strawman design

[Rémi Forax]

Le 15/05/2010 21:23, Doug Lea a écrit :
> On 05/15/10 13:34, Brian Goetz wrote:
>    
>>> 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?
>>
>>      
> Another choice is VM plus linking tools.
> If front-end compilers stay dumb and just put out the "obvious" code,
> it would be a good idea to offer developers a choice of
> whether they wanted fast vs dynamic via optional additional tools.
> With closures, it seems a sure thing that people will want to develop
> such tools anyway to get better performance for constructs that
> VMs don't always cope all that well with. As was pointed out last
> week by Nathan Bryant:
>    
[...]
> There is no need for front-end compilers to do this inlining etc either.
> It strikes me that jar-packaging tools might turn into optimizing
> linking tools to address a bunch of related performance problems at
> once.
>
>
> -Doug
>    

Premature optimization is the root of all evil :)

The object that represents a closure already exists,
it's java.dyn.MethodHandle.
If the JIT is not able to optimize correctly a common use case
the solution is to improve the JIT.

Rémi