Using the "protected" access modifier with inheritance

[Nyeng Gyang]

The definition of the “protected” access specifier for a class member (whether this class member is an instance method or an instance variable) of class A is that a class member with this access specifier in class A would be accessible from (1) All classes that are in the same package as class A and (2) All classes that are subclasses of class A.

Despite the foregoing definition of the “protected” access specifier for a class member, it appears like there is a condition under which a class member with this access specifier in class A will nonetheless not be accessible from a subclass of class A and this condition entails the following:

(1.) Class B is a subclass of class A.
(2.) Class B is in a different package than class A.
(3.) An instance of class A is made to access a class member of class A from within class B.

In other words, when this access specifier is used for a class member of class A, this class member will not be accessible from class B (when class B meets only the subclass criterion, but not the same package criterion for the definition of this access specifier for a class member), because of the action in point number 3 above.

The following code illustrates what I have just explained in the foregoing:

package packages.testpackage;//This code is saved in a file named TestingMethods.java and placed in the following folder: ...\packages\testpackage
public class TestingMethods
{
   protected void method1(int... a)
   {
      System.out.println(a.length);
   }
}

package packages;//This code is saved in a file named TestingAccessSpecifiers.java and placed in the following folder: ...\packages
import packages.testpackage.*;
public class TestingAccessSpecifiers extends TestingMethods
{
   void method2()
   {
      TestingMethods a  = new TestingAccessSpecifiers();
      a.method1(2, 4, 5, 6);
   }
   
   public static void main(String... args)
   {
      new TestingAccessSpecifiers().method2();
   }
}

The foregoing code demonstrates that there clearly is the aforementioned caveat to the definition of the “protected” access specifier for a class member (i.e., when this access  specifier is used for a class member of class A, there is a condition under which the class member will not be accessible from a subclass of class A). This caveat is discussed in the study guide written by Boyarsky and Selikoff (i.e., OCP: Java SE 11 Developer Complete Study Guide). What do you think about this?

[Campbell Ritchie]

Nyeng Gyang wrote:. . . accessible from (1) All classes that are in the same package as class A and (2) All classes that are subclasses of class A. . . .

Please always say where such information comes from. That definition is incorrect, anyway. The correct definition is in the Java® Language Specification (=JLS).

What do you think about this?

It makes protected access hard to understand.

[Tim Holloway]

We have recently discussed the operation of protected in another thread.

In your example, the reason that an "A" in class "B" cannot access private/protected methods of class A is that you're attempting to externally access those methods.

That is, you have an instance of "A" named "a" and you're trying to invoke the forbidden method using "a" as the method target. If the target of the protected method had been "this" or "super", you'd be doing an internal access which is what protected allows.

[Campbell Ritchie]

Tim Holloway wrote:. . . another thread.

I think this is that thread.

. . . you have an instance of "A" named "a" and you're trying to invoke the forbidden method using "a" as the method target.

Did you (NG) read the JLS section? Such calls don't constitute part of the object.

If the target of the protected method had been "this" or "super", . . .

. . . that does constitute implementing the object.

[Nyeng Gyang]

Thanks, gentlemen, for taking the time to read and then respond to my inquiry. I checked the JLS, to which Campbell referred me, and discovered that the correct definition for the “protected” access specifier for a class member actually does include the caveat to the definition that I provided in my initial post above (in other words, this caveat is actually not separate from and in addition to this definition, but an integral/inseperable part of the definition).

In particular, the JLS explains thus:

(1.) "A protected member or constructor of an object may be accessed from outside the package in which it is declared only by code that is responsible for the implementation of that object.

(2.) "The fields x and y are declared protected and are accessible outside the package points only in subclasses of class Point, and only when they are fields of objects that are being implemented by the code that is accessing them."

Nearly all the definitions that one gets, for the “protected” access specifier for a class member, from Googling this topic, provide the incomplete definition I furnished in my initial post above; this includes even the following source, which is an official Oracle documentation: The Java™ Tutorials (I suppose this answers Campbell's question about where that incomplete definition I furnished came from).

Based on the aforementioned definition furnished in the JLS, I can see how, because the code of the TestingAccessSpecifiers class is not responsible for the implementation of the instantiated object of the TestingMethods class, the call to the "protected" method member, of the TestingMethods class, by an object of the TestingMethods class fails to meet the defined requirement of legal access to a "protected" member of a class.

[Campbell Ritchie]

Nyeng Gyang wrote:. . . Googling this topic . . .

Beware: it takes a lot of experience to work out whether the site you found provides really good information or a load of old rubbish.

The Java™ Tutorials . . .

I quote the Java™ Tutorials all the time, but I am aware of places where they differ from the official JLS definitions. Remember the JLS is definitive, or take shortcuts for the sake of clarity. The people who wrote the Java™ Tutorials were aware of that. They explain themselves like this:-

The Same Tutorials page as before wrote:Many of the examples in the tutorial . . . not recommended for production code.

I think it might be better to call their definition incomplete than wrong.

[Tim Holloway]

Campbell Ritchie wrote:I think it might be better to call their definition incomplete than wrong.

More precisely, they are illustrative. The examples are often "complete", but they are frequently not robust. They showcase the topic that they are explaining, but in actual developmental use, they would typically be surrounded by lots of try/catch, infrastructure code, and other things that, if included in the tutorials, would cause the topic being taught to get lost in the crowd.