Enthuware. Why can't a default method in an interface be final?

One of the questions in an Enthuware mock exam used this piece of information: "interface methods can never be declared final."

But I was trying to understand - why can't a default interface method be marked final?
After all, it has a body and perhaps the designer of the interface doesn't want it to be redefined.

interface Measurement {    public final default int getUnit() {return 1;} // DOES NOT COMPILE }

Interesting question.  I suppose they could change the rules to allow this, if they wanted to.  My guess is that they never saw a particular use case for it.  If someone does want to do this, they can also just make an abstract class instead, with a mix of concrete and abstract methods.  I'm guessing they wanted to keep the rules for interfaces a little cleaner.

Mike Simmons wrote:Interesting question.  I suppose they could change the rules to allow this, if they wanted to.  My guess is that they never saw a particular use case for it.  If someone does want to do this, they can also just make an abstract class instead, with a mix of concrete and abstract methods.  I'm guessing they wanted to keep the rules for interfaces a little cleaner.

thank you - I thought you would say - "go read the JLS".

I think the reason is that it would prevent you from solving the issue where you inherit a default method with the same name from two different interfaces.

Stephan van Hulst wrote:I think the reason is that it would prevent you from solving the issue where you inherit a default method with the same name from two different interfaces.

I agree!

Good point.  Though if the methods have incompatible return types but the same name, there's no way to fix that.  But making sure you could resolve the problem for compatible return types at least, that makes sense.

As I recall... my impression, at least... was that interfaces were intentionally kept simpler and more flexible than abstract classes, with the idea that you would never put an implementation in an interface, but that sort of thing would always go into a class, whether concrete or abstract.  There were always some loopholes in that idea, but they added much larger loopholes when they started allowing static, default, and private methods in interfaces.  But even then, they never violated the idea that a new implementation of an interface could provide a new implementation of each method.  That was the whole idea, originally at least.  And it seems that they're still clinging to it...

Also, I forgot...

Anil, go read the JLS!

Mike Simmons wrote:Anil, go read the JLS!

I haven't read the JLS much, but from what I've seen it really doesn't go into explaining why the rules are the way they are. For example there's a rule which says that the numeric literal 2147483648 can only appear in a context where it's preceded by the unary - operator. Now if you understand how 32 bits are used to contain signed integer numbers you can see why that is. But if you don't, then it's a mystery. It's as if they use "Never explain, never apologize" as a working principle.

While a class implementing an interface may have to redefine a default method if it inherits the same from two interfaces, there is no such issue with a static method. But even a static method can't be marked final in an interface! One can only guess why.

Mike Simmons wrote:Also, I forgot...

Anil, go read the JLS!

I don't intend to because I believe it is for Java language specialists, University researchers, geeks and those who write Java language tools.
I only want to complete this certification. For myself, Java is like a pet pig that grew wings gradually especially after version 5 and has now flown away, out of reach.
If everything was "read the JLS", we wouldn't need textbooks nor any Java books.
I do understand there are corner cases not covered in some books - like the one in my other thread.

Paul Anilprem wrote:But even a static method can't be marked final in an interface! One can only guess why.

What would it even mean for a static interface method to be final? Static interface methods aren't inherited in the first place.

Anil Philip wrote:. . . I don't intend to . . . .

What a shortsighted approach to it

Stephan van Hulst wrote:

Paul Anilprem wrote:But even a static method can't be marked final in an interface! One can only guess why.

What would it even mean for a static interface method to be final? Static interface methods aren't inherited in the first place.

It would mean the same that it does for a class. That it can't be hidden!

But static interface methods can't be hidden at all anyway. The final modifier would not serve any additional purpose, and therefore the choice was made to disallow it.