Lambda's/Closures & Extension Methods in JDK 1.6

[Neal Gafter]

As I've repeated before, changing the default of defender methods is the one
kind of change that the defender method proposal does not discuss in its
binary compatibility section.  It doesn't make sense to criticize another
proposal for exactly the same problem that the defender method proposal
suffers from.

On Wed, Sep 29, 2010 at 8:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> > As I mentioned, I'm currently using them without even changing the
> compiler.
> > They work well, but I find the syntax a bit cumbersome. I haven't found
> any
> > brittle class issues. I should mention that the syntax was cumbersome
> enough
> > that I didn't use them for about a year, until I started using lambdas.
> Now
> > they have become more essential.
> >
> > Did you try out the solution?
>
> A compiler-only solution fails on the following case:
>
> interface Foo {
>   public extension void foo() default X.a();
> }
>
> interface Bar extends Foo {
> }
>
> class C implements Bar { }
>
> // Compile the above classes, then recompile Bar with:
>
> interface Bar extends Foo {
>   public extension void foo() default X.b();
> }
>
> // Re-run your program.  Now behavior of C is wrong; you call the wrong
> default when C.foo() is called.
>
>
>