• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

overriding static methods

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And Welcome to JavaRanch Poorvika
 
Master Rancher
Posts: 4222
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 62
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason is because ..

 
Mike Simmons
Master Rancher
Posts: 4222
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 62
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4222
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 63
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



The above line will not compile saying that

clientCodeShouldNotBreak(Child) in TestJava cannot be applied to (Parent)
 
Ranch Hand
Posts: 227
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@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
Posts: 62
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 227
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).
 
Marshal
Posts: 75842
361
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic