The most successful people in any walks of lives may not be the most talented ones but are definately the most passionate & dedicated ones.

Monday, August 23, 2010

Can we override a static method in java? [Overridding v/s hiding]

Can we override a static method?

This answer is NO, albeit the compiler allows us to write the code which is same as overriding any method in java but the compiler doesn't provides us the benefits of overriding i.e. dynamic object lookup during run-time and hence we say that we can't override static methods in java.

The below explanation would make it crystal clear.

class Foo {
public static void method() {
System.out.println("in Foo");
}
}

class Bar extends Foo {
public static void method() {
System.out.println("in Bar");
}
}
This compiles and runs just fine. Isn't it an example of a static method overriding another static method? The answer is no - it's an example of a static method hiding another static method. If you try to override a static method, the compiler doesn't actually stop you - it just doesn't do what you think it does.

So what's the difference?

Briefly, when you override a method, you still get the benefits of run-time polymorphism, and when you hide, you don't. So what does that mean? Take a look at this code:
class Foo {
public static void classMethod() {
System.out.println("classMethod() in Foo");
}

public void instanceMethod() {
System.out.println("instanceMethod() in Foo");
}
}

class Bar extends Foo {
public static void classMethod() {
System.out.println("classMethod() in Bar");
}

public void instanceMethod() {
System.out.println("instanceMethod() in Bar");
}
}

class Test {
public static void main(String[] args) {
Foo f = new Bar();
f.instanceMethod();
f.classMethod();
}
}
If you run this, the output is

instanceMethod() in Bar
classMethod() in Foo

Why do we get instanceMethod from Bar, but classMethod() from Foo? Aren't we using the same instance f to access both of these? Yes we are - but since one is overriding and the other is hiding, we see different behavior.

Since instanceMethod() is an instance method, in which Bar overrides the method from Foo, at run time the JVM uses the actual class of the instance f to determine which method to run. Although f was declared as a Foo, the actual instance we created was a new Bar(). So at runtime, the JVM finds that f is a Bar instance, and so it calls instanceMethod() in Bar rather than the one in Foo. That's how Java normally works for instance methods.

With classMethod() though. since it's a class method, the compiler and JVM don't expect to need an actual instance to invoke the method. And even if you provide one (which we did: the instance referred to by f) the JVM will never look at it. The compiler will only look at the declared type of the reference, and use that declared type to determine, at compile time, which method to call. Since f is declared as type Foo, the compiler looks at f.classMethod() and decides it means Foo.classMethod. It doesn't matter that the instance referred to by f is actually a Bar - for static methods, the compiler only uses the declared type of the reference. That's what we mean when we say a static method does not have run-time polymorphism.

Because instance methods and class methods have this important difference in behavior, we use different terms - "overriding" for instance methods and "hiding" for class methods - to distinguish between the two cases. And when we say you can't override a static method, what that means is that even if you write code that looks like it's overriding a static method -- it won't behave like an overridden method.

So what about accessing a static method using an instance?

It's possible in Java to write something like:

f.classMethod();

where f is an instance of some class, and classMethod() is a class method (i.e. a static method) of that class. This is legal, but it's a bad idea because it creates confusion. The actual instance f is not really important here. Only the declared type of f matters. That is, what class is f declared to be? Since classMethod() is static, the class of f (as determined by the compiler at compile time) is all we need.

Rather than writing:

f.classMethod();

It would be better coding style to write either:

Foo.classMethod();

or

Bar.classMethod();

That way, it is crystal clear which class method you would like to call. It is also clear that the method you are calling is indeed a class method.

Why does the compiler sometimes talk about overriding static methods?
The Java Language Specification is very clear about the difference between overriding and hiding, even if the compiler messages are not. Sometimes you will see error messages from the compiler that talk about overriding static methods. Apparently, whoever writes these particular messages has not read the Java Language Specification and does not know the difference between overriding and hiding. So they use incorrect and misleading terminology. Just ignore it.


Please correct me if any code snippet / concept is not right and have been inadvertently stated above as a typo.

Happy Learning !!!
--Vinay

Thanks

No comments:

Post a Comment