Enthuware

Posted: **Sun Jun 14, 2020 1:03 pm**

Greetings,

I can understand An interface can redeclare a default method and provide a different implementation. because it works like an Override.

But I don't understand the reasoning behind An interface can redeclare a default method and also make it abstract. I can just memorize this fact for the test, but It would be easy to forget if I do not understand the reasoning behind this.

Below are my hypothesis:
1. Because abstract and default keywords can go together -> WRONG. The book also states, "a method cannot be default as well as abstract at the same time".

Code: Select all

//abstract default String getId(); //1 Will not compile
//default abstract String getId(); //2 Will not compile

2. Because all methods without body inside an interface are automatically treated as abstract -> WRONG

Code: Select all

//public default String getId(); //3 Will not compile because the kw [i]default[/i] is present

3. Because this is not an Override -> WRONG
Adding @Override allows the code to compile fine

4. Because the child method only has the same name, but is a completely new method. -> WRONG

Code: Select all

void getId(); //Changing the child method return type. This is treated as an Override and requires a covariant return type, so it will not compile.

5. An overriding method is allowed to strip the default keyword from the overridden method. -> This kinda makes sense because Java should allow inheriting interfaces/classes/abstract classes to strip the default keyword and make their own implementations.
5b. Unlike accessibility modifiers(private, package, protected, public), the keywords abstract and default do not affect Overridability whatsoever?

Are my reasonings in #5 and #5b correct? If not, then can you explain the concept behind
An interface can redeclare a default method and also make it abstract.
a little bit more?

Thanks.

Posted: **Mon Jun 15, 2020 12:48 am**

I don't know the exact reason for this rule but my guess is that it makes logical sense. By letting a subinterface redeclare a default method as abstract, you are just saying that you don't want to provide any default implementation. You want the class implementing this interface to provide an implementation. This is how interfaces have always been, before default methods.

Since there is no logical contradiction anywhere in this requirement, I don't see a reason to disallow it.

BTW, interfaces do not exactly "override" any method (even if @override succeeds) in the same sense that classes do. They just provide an implementation of their own for a given method through default methods. You can't call super interface's method using super dot syntax in an interface's default method (which would have been possible, had it been a real override.)

Posted: **Mon Jun 15, 2020 2:27 am**

BTW, interfaces do not exactly "override" any method (even if @override succeeds) in the same sense that classes do. They just provide an implementation of their own for a given method through default methods. You can't call super interface's method using super dot syntax in an interface's default method (which would have been possible, had it been a real override.)

This behavior is interesting to note, indeed. It is not an override, yet we are forced to keep the same return type.

It looks like your reasoning and my reasoning #5 are pretty much the same. The concept is much clearer now with your explanation. Thanks!

Posted: **Thu Jun 25, 2020 6:07 pm**

I am trying to paraphrase this explanation,

Trying to override a static method with a non-static method (and vice-versa) in a class will result in a compilation error. Even in case of interfaces, a subinterface cannot override a default method with a static method. You can, however, have a default method in a subinterface with the same signature as a static method of its super interface because a static method of an interface can only be called using that interface's name.

in a way that is easier for me to remember,

Trying to override a static method with a non-static method (and vice-versa) in a class, abstract class, or interface will result in a compilation error.

The only exception to this rule is: you can have a default method in a subinterface with the same signature as a static method of its super interface because a static method of an interface can only be called using that interface's name.

Tested code:
The only scenario where it does compile

Code: Select all

//interface C {static void test(){}}
//interface D extends C {default void test(){}}

All the scenarios below will not compile

Code: Select all

//class A {static void test(){}}
//class B extends A{void test(){}}

//class A {void test(){}}
//class B extends A{static void test(){}}

//interface C {default void test(){}}
//interface D extends C {static void test(){}}

//abstract class C {void test(){}}
//abstract class D extends C {static void test(){}}

//abstract class C {static void test(){}}
//abstract class D extends C {void test(){}}

Is there any other exception to this rule that I should be aware of?

Posted: **Thu Jun 25, 2020 9:01 pm**

No, that's the only one.

Enthuware

About Question enthuware.ocpjp.i.v11.2.1481 :

About Question enthuware.ocpjp.i.v11.2.1481 :

Re: About Question enthuware.ocpjp.i.v11.2.1481 :

Re: About Question enthuware.ocpjp.i.v11.2.1481 :

Re: About Question enthuware.ocpjp.i.v11.2.1481 :

Re: About Question enthuware.ocpjp.i.v11.2.1481 :