method overriding

[blossom belle]

interface p
{
default void m(){System.out.println("p");}
}

interface c extends p
{
default void m(){System.out.println("c");}
}

class d implements p,a
{

p ob=new d();
ob.m(); // line 1

}


1. line 1 calls c's m().  Is this because it overrides and hence replaces p's version of m(). but d implements both p and c . so is there no way to get p's m() executed ? and then , it is c that overrides p's m(). but when p is also inherited in d, then why is only c's m() the one that is being executed, even though the general implementation of m() is inherited in d ?

2. and the call to c's version of m() is anyways resolved at runtime only ! at compile time , how does the compiler handle this ambiguity in class d : where d inherits d's version of m() from class p , and d also inherits an overriden version of m() from c

[Henry Wong]

shambhavi sham wrote:
1. line 1 calls c's m().  Is this because it overrides and hence replaces p's version of m(). but d implements both p and c . so is there no way to get p's m() executed ? and then , it is c that overrides p's m(). but when p is also inherited in d, then why is only c's m() the one that is being executed, even though the general implementation of m() is inherited in d ?

2. and the call to c's version of m() is anyways resolved at runtime only ! at compile time , how does the compiler handle this ambiguity in class d : where d inherits d's version of m() from class p , and d also inherits an overriden version of m() from c

First of all, this code will *not* compile. Java statements, that are not declarations need to be defined in initializers, constructors, or methods.

Second, this is not really method overriding either. Method overriding is for classes -- not really for default methods declared in interfaces.

With default methods, they are only needed, if and only if, the class does not defined them or inherits them from its superclass. In the case where the class needs the method, and they are available from multiple interfaces, it is considered ambiguous, and hence, compiler error.... except....

The exception to this rule is when the interfaces extends each other; in that case then the sub interface method gets chosen... And all of this is done at compile time. Of course, there is still a runtime component, but since there isn't any method overriding, it can only resolve to the "d" class (where it is first "implements").

Henry

[blossom belle]

1. But Henry, in books this is how they have written, the word overridden is used. For example here is one such paragraph :

A default method within an interface defi nes an abstract method with a default implementation.
In this manner, classes have the option to override the default method if they
need to, but they are not required to do so. If the class doesn’t override the method, the
default implementation will be used. In this manner, the method definition is concrete, not
abstract.

and hence I used the term !  

2. Ya I just realized I should have put class d's statements inside the main method . sorry !  

[Jeanne Boyarsky]

Henry,
That's true. I explain it as overriding because it works the same way and is easier to understand.

[blossom belle]

Henry Wong wrote:

shambhavi sham wrote:


The exception to this rule is when the interfaces extends each other; in that case then the sub interface method gets chosen... And all of this is done at compile time. Of course, there is still a runtime component, but since there isn't any method overriding, it can only resolve to the "d" class (where it is first "implements").

Henry

so the reason why the sub interface method gets chosen is probably because it has all of the parent's properties too ? and hence avoids a duplicate ?

[Henry Wong]

shambhavi sham wrote:
1. But Henry, in books this is how they have written, the word overridden is used.

and hence I used the term !  

Okay, so maybe I overstepped a bit... sorry.

However, you are doing more than using the term. In your original post, you talked about overriding, along with polymorphism, and the runtime mechanism, with the default methods of the interface.... and these behaviors are simply not the same between classes and interfaces.

Henry

[Paul Anilprem]

Please delete. Not relevant here.

[blossom belle]

Paul Anilprem wrote:Please delete. Not relevant here.

did you mean me to delete anything ?  

[blossom belle]

shambhavi sham wrote:

Henry Wong wrote:

shambhavi sham wrote:


The exception to this rule is when the interfaces extends each other; in that case then the sub interface method gets chosen... And all of this is done at compile time. Of course, there is still a runtime component, but since there isn't any method overriding, it can only resolve to the "d" class (where it is first "implements").

Henry

so the reason why the sub interface method gets chosen is probably because it has all of the parent's properties too ? and hence avoids a duplicate ?

OK Henry whatever the confusion was...lets leave it .....so now the text in bold is my final query.....