RFR: 8004518 & 8010122 : Default methods on Map
david.holmes at oracle.com
Wed Apr 10 11:32:45 UTC 2013
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.
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
> 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();
More information about the core-libs-dev