RFR: 8004518 & 8010122 : Default methods on Map

[David Holmes]

Ulf,

The discussions you refer to have been happening over a number of years. 
We are way past that point now.

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.

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
>