Allow: implements AbstractClass

Ulf Zibis Ulf.Zibis at CoSoCo.de
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 
implementation?

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.

[1] http://cr.openjdk.java.net/~briangoetz/lambda/Defender%20Methods%20v4.pdf


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

Regards,

-Ulf





More information about the lambda-spec-observers mailing list