• 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:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

curious why static methods shawdowed don't act like variables?

 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just curious, if static methods are not really overridden in subclasses and are only really shadowed, why can't you make the accessbility modifiers more restrictive? It seems like if the static methods are really not overridden then they should behave more like varaibles that are really only shadowed.
For example:


I'm sure there is a logical good explanation, I just don't see it at the moment for static methods.
 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

if static methods are not really overridden in subclasses


I don't see why this isn't overriding. (can't find this in the literature either).
In that perspective it just follows the rules that an overriding method can't be declared more private....
Erik Dark
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Erik,
here is some literature:
JLS 8.4.6 Inheritance, Overriding, and Hiding
HIH
 
Rick Reumann
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Erik Dark:

I don't see why this isn't overriding. (can't find this in the literature either).
In that perspective it just follows the rules that an overriding method can't be declared more private....
Erik Dark


It's definitely not overriding. Try the following code:

[ February 11, 2002: Message edited by: Rick Reumann ]
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, we have the access to static method which is declared as Public in Outer class from class Test. In this case it won't allow you to hide it from sub class. see the following code it will compiles fine.

class Outer
{
public static int i = 5;
// public static void doStuff()
// { }
private static void doStuff() { }
}

public class Test extends Outer
{
private static int i = 6; //ok
//private static void doStuff() {} //nope
public static void doStuff() {}// this is ok
}
 
Rick Reumann
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bhushan, you just flipped the modifiers around. I definitely understand it will compile correctly that way (althought still be careful because you haven't really overrid the static method in the subclass). Statics methods don't behave that way so I'm just curious why they don't act like variables which are shadowed in subclasses, in which case the subclass could have a static method with the same signature as the superclass yet it is more restrictive in accessibility. ( I know it doesn't work that way, I'm just curious if there is a reason why ).
 
Erik Dark
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JLS:

The access modifier of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs. If the overridden or hidden method is public, then the overriding or hiding method must be public; otherwise, a compile-time error occurs.


So Valentin, can I conclude from this that hiding and overriding both follow the rule of not narrowing the access modifier?
If so I wonder why you just gave me the lead to the correct answer (thanx for that) and didn't answer Rick's initial question...
Erik Dark
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So Valentin, can I conclude from this that hiding and overriding both follow the rule of not narrowing the access modifier?


You are right. That rule is stated in 8.4.6.3 Requirements in Overriding and Hiding

If so I wonder why you just gave me the lead to the correct answer (thanx for that) and didn't answer Rick's initial question...


Because it is better that way. You learn more from doing it yourself
HIH
 
Whose rules are you playing by? This tiny ad doesn't respect those rules:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic