• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
Sheriffs:
  • Devaka Cooray
  • paul wheaton
  • Mark Herschberg
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Frits Walraven
  • Jj Roberts
Bartenders:
  • Carey Brown
  • salvin francis
  • Piet Souris

Using the "protected" access modifier with inheritance

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:



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?
 
Marshal
Posts: 72059
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Saloon Keeper
Posts: 23263
158
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 72059
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 72059
312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 23263
158
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
I'm so happy! And I wish to make this tiny ad happy too:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic