What does reabstraction mean?

[Brian Goetz]

There have been some strong opinions stated here about the syntactic 
form used to denote reabstraction of a default method.  Let's take look 
at a somewhat deeper question: what *should* reabstraction mean in the 
context of an interface method?

Concrete class methods can be reabstracted today:

class A {
     void m() { ... }
}

abstract class B extends A {
     abstract void m();
}

class C extends B {
     void m() { ... }
}

The motivation is simple: a subclass can impose semantics which it has 
reason to believe the superclass implementation cannot provide, so it 
wants to veto the existing implementation and force a new one to be 
provided.

The current extension methods design calls for the ability to 
"reabstract" a default as well; the motivation is the same.  I'll use 
the more explicit "default none" to denote reabstraction here, for 
clarity.

interface I {
     void m() default { ... }
}

interface J extends I {
     void m() default none;
}

But, with multiple inheritance, there are at least two realistic choices 
for what this means:

  - Strong: reabstraction means "this class needs an implementation of 
m(), which must be provided by one of my subtypes."

  - Weak: reabstraction means "this class needs an implementation of 
m(), but don't use the one(s) provided by my supertype(s)."

In the single-inheritance case, both of these collapse to being the same 
thing, so analogies with existing class reabstraction offer us little 
guidance here.  (With multiple inheritance, we also have to resolve how 
they should interact with other declarations in the hierarchy that are 
not related by subtyping, such as those that arise from "C extends A, B" 
structures.)


Ignoring the details of how they fit into the language feature as it 
currently stands, which of these interpretations seems more compelling, 
natural, or powerful for the purposes of building safe and useful libraries?