RFR: 8004518 & 8010122 : Default methods on Map

Ulf Zibis Ulf.Zibis at CoSoCo.de
Wed Apr 10 10:19:42 PDT 2013

Thanks David,

Am 10.04.2013 13:32, schrieb David Holmes:
> Ulf,
> The discussions you refer to have been happening over a number of years. We are way past that 
> point now.

Yes, it's a pity, that I haven't followed those discussions early enough. Theoretically, Java 8 is 
not final now, but I understand, that changing this now would be a BIG work.

> The key point is that default methods do not introduce multiple-inheritance of state, which is 
> where the MI problems lie, and why we would not want to add MI and use abstract classes.

Yes, that's what I meant with some restrictions on abstract classes to be "implementable", they 
should be stateless, at least for the first round. My main concern was about the complicated/ugly 
syntax and priority priority rules on the default method approach.

Thanks for your feedback,


> Regards,
> David
> On 10/04/2013 6:47 PM, Ulf Zibis wrote:
>> Hi all,
>> when I see all the extensions on interfaces via the new default
>> construct, I still have the feeling, such entities should be seen and
>> named as "normal" abstract classes. This would additionally allow
>> protected and private members, which otherwise can be a cumbersome
>> restriction.
>> To be compatible to legacy code, IMO it would be enough to extend the
>> usage of keyword "implements" for abstract classes. I'm aware, that
>> there should be some restrictions on such abstract classes to be
>> manageable as interfaces, but not as strict as for current interface
>> default method approach.
>> In fact, the interface default methods is the introduction of
>> multi-inheritance in Java throug the backdoor, so why not give it a
>> prominent full featured place and handle and name it as such?
>> Is there anybody willing to discuss the reasonable for the "lousy"
>> makeshift as I see the default method construct:
>> - verbose ugly syntax
>> - cumbersome restrictions
>> - unnecessary complicated priority rules:
>> - - some of the priority collisions could be handled by simply
>>      distinguishing between e.g. "implements Map" and "extends Map"
>>  From the call site view, I'm not aware, if it would make any
>> difference, having e.g. j.u.Map as interface or abstract class:
>>      Map myMap = new HashMap();
>>      myMap.doSomething();
>> Regards,
>> -Ulf

More information about the lambda-spec-observers mailing list