shadowing

[devesh singh]

I have doubt in the followig ques
Q)
A static method in a superclass can be shadowed by another static method in a subclass, as long as
the original method was not declared final.
a] False
b] True
answer given is true but the static method can be accessed int the child class
also through classname.methodname() then how it canbe called as shadowed

[Cindy Glass]

So where did you find this question?? I believe that they are using the word shadow incorrectly.
When a subclass has a static method that is that same name as the super class's static method, then the subclass method "hides" the super class method.
From the JLS 8.4.6.2 Hiding (by Class Methods)

If a class declares a static method, then the declaration of that method is said to hide any and all methods with the same signature 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.

When you have a variable or a field that is in a narrower scope within the SAME class but has the same name, then it is shadowed. So an instance variable x in a class that has a method that ALSO has a (different) variable x causes shadowing. It makes it harder to manipulate the x that is outside the method while you are in the method.

From the JLS 6.3.1 Shadowing Declarations

Some declarations may be shadowed in part of their scope by another declaration of the same name, in which case a simple name cannot be used to refer to the declared entity.

And there is still obscuring, which is when two "things" of different types have the same name. Like if you have a class abc and then you name one of the variables IN the class abc, it becomes difficult for the JVM to know WHICH abc that you are talking about at any given time (cause you have obsured the names), so there are rules that control this situation.

A simple name may occur in contexts where it may potentially be interpreted as the name of a variable, a type or a package. In these situations, the rules of �6.5 specify that a variable will be chosen in preference to a type, and that a type will be chosen in preference to a package. Thus, it is may sometimes be impossible to refer to a visible type or package declaration via its simple name. We say that such a declaration is obscured.

[This message has been edited by Cindy Glass (edited May 08, 2001).]

[Cindy Glass]

Oh by the way, the answer to your question (now that I am done rambling)

8.4.3.3 final Methods
A method can be declared final to prevent subclasses from overriding or hiding it. It is a compile-time error to attempt to override or hide a final method.

So that part is explained, and if he had used the word hidden it would be true. It is hidden because it can not be called directly, as it could have been if it were not shadowed. Because it is hidden you have to use the classname to get at it.
Note that you cannot use the super.method syntax because it is not overridden.

[James Du]

Hi, here the defination of shadow of method in jls

A declaration d of a method named n shadows the declarations of any other methods named n that are in an enclosing scope at the point where d occurs throughout the scope of d.

Cindy, I dont think hide necessarily contrdict shadow, shadow is a more inclusive concept apply to all kinds of declaration while hide just apply to static methods that conform to some conditions.Specifically, a method hides another method not means the method definately not shodow another one.
pls. consider the following code

class Base
{
    static void show()
    {
        System.out.println("show in Base");
    }
}
class Sub extends Base
{
    // both hides and shodows the declaration of show() in the Base
    static void show()
    {
        System.out.println("show in Sub");
    }
    static void callShow()
    {
        // the 2 versions of method show() declared in Base & Sub are all in scope at the point
        // according to the quote, the Base version of show() was shadowed by the Sub version one
        // if it were not for the show() declared in Sub, show() in the Base would be called
        show();
// if the Base version intended, qualified name must be used instead of simple name
// that's what defination described
Base.show();
    }
    static void main(String[] args)
    {
        callShow();
    }
}

As for the devesh's question:
A static method in a superclass can be shadowed by another static method in a subclass, as long as
the original method was not declared final.
If the final changed to private, i think the answer should be ture.
Let's still take the above code for example, if the show() declared private in Base, then in the body of class Sub, show() of Base was not in the scope(it even not accessible, say nothing of refered to using the simple name), so in this case, it cant be said shadowed
If i'm wrong, pls. correct me.
James

[Cindy Glass]

No I am sorry, but the Java Language Specification is VERY clear on this point. They are very different things. Shadowing ONLY involves scope. Hiding ONLY involves inheritance. Obscuring ONLY involves types.

From the JLS

6.3.1 Shadowing Declarations
Note that shadowing is distinct from hiding (�8.3, �8.4.6.2, �8.5, �9.3, �9.5). Hiding, in the technical sense defined in this specification, applies only to members which would otherwise be inherited but are not because of a declaration in a subclass. Shadowing is also distinct from obscuring (�6.3.2).

Notice how carefully they distinquish between the two:

If the class declares a field with a certain name, then the declaration of that field is said to hide any and all accessible declarations of fields with the same name in
superclasses, and superinterfaces of the class. The field declaration also shadows (�6.3.1) declarations of any accessible fields in enclosing classes or interfaces, and any local variables, formal method parameters, and exception handler parameters with the same name in any enclosing blocks.

[This message has been edited by Cindy Glass (edited May 09, 2001).]

[Brett Delia]

Is this not just a case of overriding a method of the parent class? At least that is how I read it.

[Cindy Glass]

No - overriding is done with late binding. Hiding is done at compile time. That is why static methods in a subclass are said to "hide" static methods with the same signature in a parent class.
You get at hidden methods differently then you get at overridden methods, so you need to understand the difference.

[James Du]

Hi Cindy, let me restate what you said here.

originally posted by Cindy
They are very different things. Shadowing ONLY involves scope. Hiding ONLY involves inheritance. Obscuring ONLY involves types.

Yes, I admit that they are very different things, but my viewpoint is:
Just because they are distinct concepts, one thing could conform to both from different perspectives.In other words, at the standpoint of hiding, it's the case of hiding; at the standpoint of shadowing, it could be considered a case of shadowing.
Pls. look at the following code.
class Base
{
static void show(){System.out.println("show in Base");}
}
class Sub extends Base
{
static void show(){System.out.println("show in Sub");}
}
I think the method show() in class Sub could be considered shadows the one in class Base from the perspective of scope, tell me if i am worong? if i am, pls. tell me which condition it doesn't meet as to being a case of shadow.

[Cindy Glass]

According to the JLS you are wrong. It hides it.
In order for Sub's show() method to shadow Base's show class, it must be in a NARROWER scope than Base, which means that Bases scope must CONTAIN it. In your example it is not in any way in the same scope. They are in separate scopes completely, related only by the fact of inheritance.
However if you set it up this way:

<font size=2.5>
class Base
   {
      static void show(){System.out.println("show in Base");}
   
    class Inner 
       {
          int i = 0;
          static void show(){
               System.out.println("show in Inner");
               int i = 1;
               }
       }
}

Inner's show method shadows Base's show method. There is not subclassing going on here, just a matter of scope. Also Show's i shadows Inners i, because it is in a narrower scope.

[James Du]

Yes, I think i am wrong.
I misunderstood the concept of inheritance. I supposed that overridden and hidden methods are also inherited but be overridden or hidden afterwards, and according to the following state in jls, I throught that the scope of show() in base contains the scope of show() in sub.

The scope of a declaration of a member m declared in or inherited by a class type C is the entire body of C, including any nested type declarations.

Howerer, when I checked the defination of inherits in jls, I found this:

A class inherits from its direct superclass and direct superinterfaces all the non-private methods (whether abstract or not) of the superclass and superinterfaces that are accessible to code in the class and are neither overridden (��8.4.6.1) nor hidden (��8.4.6.2) by a declaration in the class.

Overridden and hidden methods never inherited at all! and the private methods, the scope of these declaration is confined within the class in which they appeared. Therefore, shadow is not applicable here!
Thanks, Cindy, thanks a million!
If there's still something wrong in my statement, tell me!
Regards,
James