Default method survey results
peter.levart at marand.si
Thu Aug 16 08:27:08 PDT 2012
On Thursday, August 16, 2012 04:22:26 PM Peter Levart wrote:
> On Thursday, August 16, 2012 02:33:41 PM Maurizio Cimadamore wrote:
> > I think default != concrete - at least under some interpretations of it.
> > In the example I gave, you have a concrete method that does not override
> > an abstract method in the superclass, because superclass methods always
> > win, even if abstract. This is what, in my mind at least, makes a
> > default method a different beast.
> Ok, I understand the reasoning now. To recap:
> Java 8 (will) have 3 types of public (or virtual) methods:
> - concrete methods (only in classes)
> - abstract methods (in classes and interfaces)
> - default methods (only in interfaces)
> - concrete methods do not have a modifier
> - abstract methods have "abstract" modifier (which is implicit in
> interfaces) - default methods have "default" modifier
On the other hand, Maurizio is right. It is not the type of method (concrete,
abstract, default) that defines which one "wins", but, in the first place, the
type of the container (class or interface - class allways wins) and, in the
second place, the position of the container in the hierachy.
For example, say we have one abstract method and one default method. If the
abstract methods belongs to a class, it wins. If it belongs to an interface it
depends on the position of the interface in the hierarchy.
Its the same story when we have one abstract method and one concrete method.
If the abstract methods belongs to an interface, then concrete method wins. If
it belongs to a class it depends on the position of the class in the
So we already have one type of methods (abstract) that play differently
depending on where they are defined in (interface or class).
So do we need two types of methods with a body: concrete / default - each one
designated for a specific container interface / class, just to indicate how
they play in the hierarchy?
More information about the lambda-dev