Allow: implements AbstractClass

Ulf Zibis Ulf.Zibis at
Fri Sep 14 04:00:43 PDT 2012

Hi and hello first time on this list!

Unfortunately I not have observed the discussion on project Lambda until today.
Reading the fourth draft [1] of "Interface evolution via virtual extension methods" I was concerned 
about 3 things:
- ugly syntax
- the need of an external helper class
- is there a technical difference between an interface and an abstract class without any concrete 

And an alternative approach came to my mind ...
*Allow "implements" on abstract classes* !

If one wants to extend an interface by a method, he should only refactor it to an abstract class and 
declare an implementation as a default for that method. E.g.:
     class MyClass extends SuperClass implements AbstractClass

The rules from [1] about multiple competing defaults should apply as well, but there would be one 
extra opportunity to define the hierarchy on ambiguous methods. Example:
     abstract class A { void m() { } }
     abstract class B { void m() { } }
     class C extends A implements B { }
In this case, A.m() should have priority over B.M(), so there is no need to throw a linkage 
exception !!!

The approach also would allow another interesting possibility:
The definition of package private abstract methods to be used as package internal interface methods 
which are not visible from outer scope.


Even it that kind of thoughts have been discussed in the past, I would appreciate some conclusive 



More information about the lambda-spec-observers mailing list