RFR: 8004518 & 8010122 : Default methods on Map (original) (raw)

Ulf Zibis Ulf.Zibis at CoSoCo.de
Wed Apr 10 17:19:42 UTC 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,

-Ulf

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 core-libs-dev mailing list