Virtual extension methods -- a strawman design

[Rémi Forax]

Le 15/05/2010 03:54, Brian Goetz a écrit :

[...]

>> The proposed behavior for old class files might as well be done for all
>> classes.  That improves binary compatibility.
>>      
> Probably so.  The intent of compiler weaving (in addition to VM weaving) was
> to minimize the impact on the tools ecosystem (e.g., static code analyzers,
> IDEs, AOP tools, etc) in that classes implementing an extended interface that
> have been compiled with a current compiler will look to tools as complete
> implementations of the interface.  Would be nice if this didn't create a huge
> ripple effect through the tools ecosystem; not only would that be mean to our
> friends, but it would delay adoption.
>    

JSR 294 and JSR 292 already impact the format of the class file
breaking the compatibility.
The required changes are, in my opinion, more heavyweight than
thoses proposed in this document.
(The two specs add new constant items in the constant pool,
  and JSR292 adds a new opcode)

So If extension method are added in jdk7,
I don't buy this argument.

Rémi