Defender methods and reabstraction

[Brian Goetz]

It was pointed out to me the other day that the defender methods document does 
not properly deal with removal of a default.  The intent all along was that 
removal of a default should be analogous to reabstraction of a concrete method 
by an abstract subclass.

Syntactically, the logical way to remove a default would be to override the 
method without a default:

interface A {
     void m() default Stuff.foo;
}

interface B extends A {
     @Override
     void m();
}

It might be desirable to have a syntactic means of saying "same default as my 
parent", which might look like:

// maybe
interface B extends A {
     @Override
     void m() default super.m;  // or A.super.m
}

We'll put that one on the "things to think about" list.

Semantically, I think it makes sense to treat a reabstracted extension method 
as having a "special" default.  This allows us to have a unified approach for 
handling shadowed extension methods:

interface A {
     void m() default Stuff.foo;
}

interface B extends A {
     void m() default Stuff.moo;
}

interface C extends A {
     void m();
}

class X implements A, B {
     // m() is linked to Stuff.moo -- B default shadows A default
}

class Y implements A, C {
     void m() { ... }
     // m() implementation required here
     // even though A is directly implemented
     // as reabstraction in C shadows default in A
}

This preserves the linearization-by-topological-sort property in both cases 
"re-implementing" A is a no-op because X and Y implement more specific 
interfaces (B and C extend A, so re-implementing A has nothing left to offer 
to X and Y, and therefore can be ignored.)

I'll add this to the next round of the document.