Question about static methods in superclasses and subclasses

[Leonard Fischer]

Hello everyone, this is my first question at JavaRanch! I'm studying for the SCJP exam. I notice that I can have a static method myFun1() in a superclass A, and a static method by the same name (myFun1()) in a subclass B of A. (That is, class B extends A.) I'm surprised that I get a compiler error when I have the superclass myFun1() as default or package access, and the subclass myFun1() as private. I would expect this error if both myFun1()'s were instance methods. Obviously, we can't override an instance method in a way that reduces accessibility. But it seems that with both myFun1()'s being static, we're not even overriding anything; we're simply overloading. No polymorphism is involved; the myFun1() that is called depends entirely on the declaration type of the instance used to invoke it (if we're using an instance instead of the class itself). The compiler error actually uses the word "override". I'm confused... both myFun1()'s are static methods!

[Ruben Soto]

Hi Leonard,

Welcome to JavaRanch!

You are correct that a static method in a subclass doesn't override (but rather hides) a static method with the same name in the superclass. Some things to keep in mind are:
- Even though static methods do not involve overriding, when you redefine (or hide) a static method like that in a subclass, you have to abide by the same rules that are in effect for instance method overriding (so you can't narrow the access level in the subclass, and you can't throw wider checked exceptions either. Also, the return types must be compatible in the same way they must be when overriding.) This has been discussed in the forum before, and it is discussed in the JLS, 3rd Edition in 8.4.8.3. (Requirements in Overriding and Hiding.)

- The terminology that you get from the compiler regarding "overriding" is not correct. This has also been discussed before. No overriding is taking place (only hiding.) However, the rules are the same.

I hope that helps.

[armando fonseca]

Hi Leonard,

I really enjoyed your example, it took me like 25 minutes to conclude the following:
First, you are not overloading, because the parameter list for both static methods are the same.
In your case, since The parameter list, the method name and return type are same for both myFun1(), what I think (not 100 percent sure), is that JVM assumes that you that are trying to override , so it then jumps to the check for an appropriate accessibility modifier ( lin other words, it jumps over the static modifier) because it seems that the access modifiers have higher priority than static/abstract/final and finds out that there is a private keyword and stops any other validation on the method's header, hence, ignoring the static context.

This is what I'm assuming, but again I understand that you want the correct answer, alright btw, Welcome to JavaRanch!

- Armando

[Ruben Soto]

armando fonseca wrote:Hi Leonard,

I really enjoyed your example, it took me like 25 minutes to conclude the following:
First, you are not overloading, because the parameter list for both static methods are the same.
In your case, since The parameter list, the method name and return type are same for both myFun1(), what I think (not 100 percent sure), is that JVM assumes that you that are trying to override , so it then jumps to the check for an appropriate accessibility modifier ( lin other words, it jumps over the static modifier) because it seems that the access modifiers have higher priority than static/abstract/final and finds out that there is a private keyword and stops any other validation on the method's header, hence, ignoring the static context.

This is what I'm assuming, but again I understand that you want the correct answer, alright btw, Welcome to JavaRanch!

- Armando

Hi Armando,

There was one time when I made similar assumptions also. Then I found out that the truth was a little different. I think my previous post in this thread explains briefly what's going on. For more details the JLS is the way to go.

[armando fonseca]

Ruben Soto wrote:

armando fonseca wrote:Hi Leonard,

I really enjoyed your example, it took me like 25 minutes to conclude the following:
First, you are not overloading, because the parameter list for both static methods are the same.
In your case, since The parameter list, the method name and return type are same for both myFun1(), what I think (not 100 percent sure), is that JVM assumes that you that are trying to override , so it then jumps to the check for an appropriate accessibility modifier ( lin other words, it jumps over the static modifier) because it seems that the access modifiers have higher priority than static/abstract/final and finds out that there is a private keyword and stops any other validation on the method's header, hence, ignoring the static context.

This is what I'm assuming, but again I understand that you want the correct answer, alright btw, Welcome to JavaRanch!

- Armando

Hi Armando,

There was one time when I made similar assumptions also. Then I found out that the truth was a little different. I think my previous post in this thread explains briefly what's going on. For more details the JLS is the way to go.

Ohh now I see way,
thank you Ruben

-Armando

[Ruben Soto]

No problem, Armando. I remember a very long thread brought up by this very same issue. You might be able to locate it via the Search function in the site. The consensus was, as I remember, that this is one of the very few instances (actually the only one I know of) where the compiler seems to be wrong in the wording of an error message.

[Shin Kudo]

static methods are also inherited. I think everything which has access modifier other than private is inherited. Here is an example:

public class Bar extends Foo {
	public static void main(String[] args) {
		Bar.foo();
		Foo.foo();
	}
}

class Foo {
	static void foo() {
		System.out.println("superclass' static");
	}
}

and the output is:

superclass' static
superclass' static

so in your case, it's overriding. The overriding method can not have more restrictive access modifier.

public class Bar extends Foo {
	public static void foo() {
		System.out.println("subclass' static");
	}
	
	public static void main(String[] args) {
		Bar.foo();
		Foo.foo();
	}
}

class Foo {
	static void foo() {
		System.out.println("superclass' static");
	}
}

and the output is:

subclass's static
superclass' static

[armando fonseca]

Shin Kudo wrote:static methods are also inherited. I think everything which has access modifier other than private is inherited. Here is an example:

public class Bar extends Foo {
	public static void main(String[] args) {
		Bar.foo();
		Foo.foo();
	}
}

class Foo {
	static void foo() {
		System.out.println("superclass' static");
	}
}

and the output is:

superclass' static
superclass' static

so in your case, it's overriding. The overriding method can not have more restrictive access modifier.

public class Bar extends Foo {
	public static void foo() {
		System.out.println("subclass' static");
	}
	
	public static void main(String[] args) {
		Bar.foo();
		Foo.foo();
	}
}

class Foo {
	static void foo() {
		System.out.println("superclass' static");
	}
}

and the output is:

subclass's static
superclass' static

There is no such thing as static method overridden,you just are hiding it the method. Read the post from Ruben, he got the solution.

- Armando

[Shin Kudo]

I've reread Chapter 2 of K&B and realized my misunderstanding. Static methods are not inherited so they can't be overridden, but they can be redefined .

[armando fonseca]

[quote=Shin Kudo]I've reread Chapter 2 of K&B and realized my misunderstanding. Static methods are not inherited so they can't be overridden, but they can be redefined .[/quote]
no, your are incorrect in the following way:
first, static methods are inherited and two,
your are hiding the method. As , ruben said, the jsl Can explain way.

[Leonard Fischer]

Thanks to all for the most interesting responses, which I'll be studying. For now, it seems clear that (in this case of static methods) we're not overloading (as Armando points out), and we're not overriding (as Ruben points out). I guess the correct term would be hiding. I'll have to look at JLS 8.4.8.3. (Requirements in Overriding and Hiding), but it makes sense that hiding should have the same requirements as overriding; you want the superclass to be able to do everything that the subclass can do.

[Vishal Gupta]

http://faq.javaranch.com/view?OverridingVsHiding