wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes overriding static methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "overriding static methods" Watch "overriding static methods" New topic
Author

overriding static methods

Poorvika Chandra
Greenhorn

Joined: Jun 27, 2011
Posts: 3
As of java static methods cannot be overriden.while doing a small example I encountered the following situation
class MySuperclass {
public static String step2() { return "Hi"; }
}
class MyClass extends MySuperclass {
private static void step2() { }
}
When I try to compile the above code it gave me the following error message "The return type is incompatible with MySuperclass.step2()".

My doubt here is when the static methods cannot be overriden ,then why compiler bothers about the return type incompatibility.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

if you define a static method which already there in super class in subclass is called hiding.

the rules for overriding and hidding are same.

from JLS:



8.4.8.2 Hiding (by Class Methods)
If a class declares a static method m, then the declaration m is said to hide any method m', where the signature of m is a subsignature (§8.4.2) of the signature of m', in the superclasses and superinterfaces of the class that would otherwise be accessible to code in the class. A compile-time error occurs if a static method hides an instance method.

In this respect, hiding of methods differs from hiding of fields (§8.3), for it is permissible for a static variable to hide an instance variable. Hiding is also distinct from shadowing (§6.3.1) and obscuring (§6.3.2).

A hidden method can be accessed by using a qualified name or by using a method invocation expression (§15.12) that contains the keyword super or a cast to a superclass type. In this respect, hiding of methods is similar to hiding of fields.

8.4.8.3 Requirements in Overriding and Hiding
If a method declaration d1 with return type R1 overrides or hides the declaration of another method d2 with return type R2, then d1 must be return-type substitutable for d2, or a compile-time error occurs. Furthermore, if R1 is not a subtype of R2, an unchecked warning must be issued (unless suppressed (§9.6.1.5)).

A method declaration must not have a throws clause that conflicts (§8.4.6) with that of any method that it overrides or hides; otherwise, a compile-time error occurs.

Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

And Welcome to JavaRanch Poorvika
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3003
    
    9
Poorvika Chandra wrote:My doubt here is when the static methods cannot be overriden ,then why compiler bothers about the return type incompatibility.

I think it's a good question - two static methods with one hiding the other are, in most respects, unrelated, separate methods, and they could have allowed completely different return types and throws clauses. But the creators of Java nonetheless chose to set up rules requiring them to be compatible in return type and throws. Why?

The only reason I can think for why the rule is set up this way, is that it makes it easier to change a static method into a non-static method, or vice versa. Personally, I do this reasonably often as my code evolves over time, so it's nice that I usually don't have to worry about incompatible return types and throws clauses.

I would, however, be interested to hear of any other ideas people have about why the rules are this way.
joy b chakravarty
Ranch Hand

Joined: May 16, 2011
Posts: 62

The reason is because ..



Cheers, Joy [SCJP 1.4, SCBCD 5.0]
get high on alcohol, algorithm or both
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3003
    
    9
Hm, that's because that code is using an instance to access a static method. That is generally a bad practice in my opinion, and it's another thing that in my opinion is probably only allowed in order to make it easier to convert instance methods to static methods, or vice versa. So I think we're saying the same thing, basically.
joy b chakravarty
Ranch Hand

Joined: May 16, 2011
Posts: 62

Calling static methods using an instance may be a bad practice but is still allowed so the java guys had to ensure that the calling/client code does not break in either ways of static method invocation.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3003
    
    9
But they didn't have to allow it - they chose to allow it. I'm saying that the decision to require return type and throws type compatibility goes together with the decision to allow calling a static method from an instance - both decisions were made for the same reason. In my opinion.
Rajesh Nagaraju
Ranch Hand

Joined: Nov 27, 2003
Posts: 57


The above line will not compile saying that

clientCodeShouldNotBreak(Child) in TestJava cannot be applied to (Parent)
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

@joy

The call will not compile, because you are passing a parent reference where a child reference is required. It will need to be changed as which will anyway solve the return type problem. So, I agree with Mike that the language designers could have allowed static hiding methods to be completely independent. IMHO that would not cause any ambiguous situations.
joy b chakravarty
Ranch Hand

Joined: May 16, 2011
Posts: 62

Firstly guys I'm really sorry and embarassed for posting non-compilable code..
What I was trying to imply is that Java guys tried to have the LSP principle going with this rule. here is the new and improved code

Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

I see the point you're making. Although, IMHO technically LSP is more about types & sub-types and the common instance-specific behaviour they are supposed to exhibit.

Nevertheless, the fact remains that there are no technical reasons (unresolvable ambiguity etc.) which could have prevented this feature (which is different from the case with overriding method returning/throwing the same or sub type/exception as the overridden method).
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38107
    
  22
Aditya Jha wrote: . . . unresolvable ambiguity etc. . . .
The idea behind Java™ was that it should be simple. If you have something which is resolved via a resoluble ambiguity, that is a complicated language, and no longer "simple".

There are some places where they failed to be simple, eg the rules for resolving overloading.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: overriding static methods
 
Similar Threads
Try to understando generic methods
Doubt in Static Methods
Couple of doubts in Comparator Interface
"Can't reference a class variable before supertype constructor has been called !! "
Compiler errors at line 7, 15 & 13