Understanding the protected access modifier and inheritance in Java

May 4th, 2008 by stevi | Filed under Java

The Java Tutorial gives the standard definition of the protected access modifier:

The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.

But what does this mean in practice? I see a lot of confusion that can be best cleared up by showing some code. Below are five classes. The first three are in one package, the second two in another:

package com.stevideter.java;
 
public class X {
    protected void doSomething() {
        System.out.println("did something");
    }
}
package com.stevideter.java;
 
public class Y extends X {
 
    protected void doSomethingElse() {
        // inherited from X
        super.doSomething();
        X x = new X();
        // visible b/c of same package
        x.doSomething();
    }
}
package com.stevideter.java;
 
public class AccessTest {
    public static void main(String[] args) {
        X x = new X();
        // visible - same package
        x.doSomething();
        Y y = new Y();
        // visible - inherited in same package
        y.doSomething();
    }
 
}
package com.stevideter.java.examples;
 
import com.stevideter.java.X;
import com.stevideter.java.Y;
 
class Z extends X {
    protected void myDoSomething() {
        // can call as part of implementation
        super.doSomething();
        X x = new X();
        x.doSomething(); // compile time error; declared in different package
    }
}
 
public class ExternalAccessTest {
 
    public static void main(String[] args) {
        X x = new X();
        x.doSomething(); // compile-time error, not visible
        Y y = new Y();
        y.doSomething(); // compile-time error, not visible
        Z z = new Z();
        z.doSomething(); // compile-time error, not visible
        z.myDoSomething();
    }
 
}

Here we see that while we operate in the same package, we can always access class X’s protected method doSomething(). Subclass Y can access it via inheritance, and AccessTest can see doSomething() for X, because it’s in the same package, and Y because Y inherited it from X and is in the same package.

In the second package, we see that access to X’s protected method is far more restricted. Subclass Z can use doSomething() as part of its own implementation. But it cannot access it via an instance of X.

ExternalAccessTest, on the other hand, simply cannot see doSomething(). This is true for X, because X and ExternalAccessTest are in different packages. But perhaps it’s surprising that it cannot see it in Z, which is in the same package as ExternalAccessTest. The reason is that although Z inherits doSomething from its parent class X, because doSomething() is in fact declared in a different package, that method is not visible in the new package.

It’s this final case that seems to cause the most confusion. Z does inherit the protected method doSomething(). But that inheritance is restricted by that protected access modifier. The inheritance doesn’t “override” the original declaration.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

tag_iconTags: | |

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

3 Responses to “Understanding the protected access modifier and inheritance in Java”.

  1. Jondean Haley :

    Thanks for the clarity Stevi. Just a couple of additional thoughts:
    - the ‘super’ in ‘super.doSomething()’ is not required
    - you may wish to add a brief note on resolution of protected static members – code within sub-types in the inheritance graph (and in different packages) can dereference/access protected static members, and they may do so by the usual static access: super-type-name.member-name.

    Thanks again for the clarity,
    Jondean.

  2. Muhammad Zafar :

    great explanation. nice work (y)

  3. There are more semantic situations surrounding protected members when you take into account subclasses in different packages.

Leave a comment.

To leave a comment, please fill in the fields below.