Why uninherited methods cannot be overriden?

[Ramsin Khoshaba]

The title says it all: if b.B extends a.A and does not inherit m(), then b.B cannot override m(). Why?

Maybe I'm asking this question because I've not truly understood "overriding," but either way I'm used to the phenomenon called polymorphism.
Could you define method overriding in terms of implementation, rather than examples?

Thank you...

[Campbell Ritchie]

If the method is not inherited, it will constitute a “new” method in your class.

[Ramsin Khoshaba]

But in C++ one may have virtual private methods, which means that they can be overridden, despite of being private.

That's one reason why I asked my first question.

[Campbell Ritchie]

You are writing Java® not C++. The languages are different. You can cause yourself dangerous confusion by thinking the two are the same.

[Steffe Wilson]

I'm not sure I fully understand your question Ramsin. However in CPP a function is termed 'virtual' to cause late binding. Java implements late binding too, but it does this by default, without requiring a 'virtual' keyword. If you refer to an overridden method in java using an object reference of the base class then at run-time the derived method will be invoked rather than the base method. Is this what you meant?

[Ramsin Khoshaba]

package a;

public class A {
	void m() {
		System.out.println("In A");
	}
	
	public static void main(String[] args) {
		A o = new b.B();
		o.m();    // outputs "In A"
	}
}

package b;

public class B extends a.A {
	public void m() {
		System.out.println("In B");
	}
}

m() from b.B does not override m() from a.A because m() is not inherited from a.A. They are actually two separate methods.
Why uninherited methods cannot be overriden, in Java?

I learned recently how access modifiers work, and I'm trying to grasp overriding in a way that does not contradict my understanding.
There are different ways to comprehend inheritance in general. Different languages and authors describe inheritance differently...

[Steffe Wilson]

class A {
    void m() {
        System.out.println("In A");
    }
}
class B extends A {
    void m() {
        System.out.println("In B");
    }
}
class Main {
    public static void main(String[] args) {
        A o = new B();
        o.m();    // outputs "In B"
    }
}

[Ramsin Khoshaba]

Steffe Wilson wrote:

class A {
    void m() {
        System.out.println("In A");
    }
}
class B extends A {
    void m() {
        System.out.println("In B");
    }
}
class Main {
    public static void main(String[] args) {
        A o = new B();
        o.m();    // outputs "In B"
    }
}

In your case, B inherits m() from A because the classes belong to the same package and m() is not private.
Inherited methods can be overridden.

[Henry Wong]

Ramsin Khoshaba wrote:
m() from b.B does not override m() from a.A because m() is not inherited from a.A. They are actually two separate methods.
Why uninherited methods cannot be overriden, in Java?

Well, the short answer to this "why" question is ... that is how it is defined in the Java Language Specification.

Unfortunately, if you want a more detailed answer than that, you probably have to contact Sun/Oracle, and hopefully, find one of the language designers, for that.

Henry

[Mark A Carter]

I'm still new, but it looks as if that's the point of access modifiers. Making a method default or private, is because you don't want the method to be inherited. If you want it inherited by all subclasses, no matter the package, it would be best to use the protected modifier.

[Bhushan Bhawsar]

We override a method when we need to provide a new implementation in our subclass, but in the first example where the classes are in different packages, the subclass has no information that there is method m () present in the super class (due to access modifiers used), so it cannot override it. We cannot override something which we can not see i.e not inherited. If we write a method m() in subclass then it will be a new method in class with no override.

[Campbell Ritchie]

Mark A Carter wrote:. . . Making a method default or private, is because you don't want the method to be inherited. If you want it inherited by all subclasses, no matter the package, it would be best to use the protected modifier.

Not quite. If you don't make a member private, then it is accessible in the same package where it can be inherited or overridden. If you mark a member protected, it is only accessible in the same package and in subclasses (well, more or less).

But as you suggest, you can use different access modifiers to make members accessible/inherited or otherwise in subclasses.

[Winston Gutkowski]

Bhushan Bhawsar wrote:We override a method when we need to provide a new implementation in our subclass, but in the first example where the classes are in different packages, the subclass has no information that there is method m () present in the super class (due to access modifiers used), so it cannot override it. We cannot override something which we can not see i.e not inherited. If we write a method m() in subclass then it will be a new method in class with no override.

Right. And, as Henry said, that's how Java defines it.

But TBH, it also just makes sense. If everything can be overridden, then what's the point of having a private (or indeed default) qualifier for a method?

Perhaps a more pertinent question: When was the last time you overrode a private method in C++, and why did you do it? I was a C++ programmer for 3 years or so, and it never even occurred to me that such a facility might exist - indeed, the whole idea of a private virtual method seems nonsensical to me; except possibly in a nested class.

Winston