aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Protected access specifier. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Protected access specifier." Watch "Protected access specifier." New topic
Author

Protected access specifier.

Sanjeev Ba
Ranch Hand

Joined: Dec 31, 2006
Posts: 40

Once the subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass, with the exception of subclasses of the subclass.

1. What is its access level for subclasses of subclass
2. Does it have the same access level for subclasses of this subclass inside and outside the subclass's package.

Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

Think of the protected access specifier as a package level + child level access specifier.

I presume you were going through the section in K&B in which the author has differentiated between default and protected.

1. If outside the package, the access level will only be child level. This means that you cannot access the member using an object and dot operator.

Rather you access it directly, within child class methods, as if this member were the child class's private member.

If inside the same package, both the dot operator and direct access are legit. This is because the dot operator is allowed only for public and default access levels.

2. 1 should clarify this point!


OCJP 6
Sanjeev Ba
Ranch Hand

Joined: Dec 31, 2006
Posts: 40

Yes, I am going through the same section.
While I understood the points you have explained, my question is about the access level of the protected members for classes which are subclasses of the subclass which inherits the members via the protected access specifier from the parent in a different package.

Example

package A;

class A{
protected int i;
}
-----------------------
package B;
import A.*;

class B extends A{
//inherits i; - but what is its access level ? - protected ?
}

-------------
package C;

import B;

class C extends B{
// is "i" accessible here.
}

------------------
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

For class B, whnich is in the same package, the member 'i' can be accessed either by dot operator or directly. Thus for B's methods, i acts as if it is default, with the addition of inherited access/direct acess because B extends A.

Yes, it will be accessible in the other package, in C. The difference will be that i will act as C's own private member, as C can see it only through inheritance, meaning C's methods can only access it directly. - I may be wrong about this one though. Someone please clarify!

The dot operator cannot be used across differing packages unless the variable is public, which defeats the purpose of a closed form of inheritance
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Pritish Chakraborty wrote:
Yes, it will be accessible in the other package, in C. The difference will be that i will act as C's own private member, as C can see it only through inheritance, meaning C's methods can only access it directly. - I may be wrong about this one though. Someone please clarify!

The dot operator cannot be used across differing packages unless the variable is public, which defeats the purpose of a closed form of inheritance



The exact wording in the JLS is ...

6.6.2 Details on protected Access

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.


The key phrase in the wording is ... "responsible for the implementation of that object". This means that code in the C class can access the i variable by dereferencing (using the dot operator) a reference variable. However, the variable must be of a type that IS-A C. Or more exact, the object being dereferenced must be determined at compile time, to be of a type that IS-A C.

Henry

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

But I thought you can't access a member of a class from a different package using dereferencing operator o.O

Please clarify, Henry..this has left me confused.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Pritish Chakraborty wrote:But I thought you can't access a member of a class from a different package using dereferencing operator o.O

Please clarify, Henry..this has left me confused.


Just try it. This works....



This however, will not compile....



Notice that, in both cases, it is a C instance -- but in the second case, the compiler will not allow the compilation because it can't confirm that the code is responsible for the implementation of that object.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40


I think that I should add a bit more color...

Pritish Chakraborty wrote:Think of the protected access specifier as a package level + child level access specifier.


This is correct. Protected access means that the variable can be accessed by all subclasses (referred in this case as "child level access") and by all classes in the same package as the class where the protected variable was declared.

Pritish Chakraborty wrote:
1. If outside the package, the access level will only be child level. This means that you cannot access the member using an object and dot operator.


As already mentioned, it is either access by subclass or within the same package... so, you are correct, if you are not within the same package, then it is only accessible by subclass.

However (and this is where it goes off track), access by subclass doesn't mean the same instance. An instance of the subclass can HAS-A instance of the same subclass. Or a subclass of the subclass. And it still fulfill the requirement of accessible by subclass.... and as mentioned, you need to follow the "responsible for the implementation of that object" rule.

Henry
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

I cannot try as I am not on the computer yet, but considering that the inherited 'i' variable acts like it is private to class C as per K&B, it shouldn't be accessible by the dot operator like that ._. this changes everything.

'Code that is responsible for the implementation of the object' - most vague gem of a JLS line I have heard all day!
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Pritish Chakraborty wrote:
I presume you were going through the section in K&B in which the author has differentiated between [b]default and protected.[/b]


Pritish Chakraborty wrote:I cannot try as I am not on the computer yet, but considering that the inherited 'i' variable acts like it is private to class C as per K&B, it shouldn't be accessible by the dot operator like that ._. this changes everything.


Even though this K&B reference has come up before, I don't have access to the book, so can't address this point. I personally suspect that something has been taken out of context, and that this phrase was used to describe a behavior, or as an analogy. Or something else.

Sorry,
Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40


I do have a confusion though....

Pritish Chakraborty wrote:I cannot try as I am not on the computer yet, but considering that the inherited 'i' variable acts like it is private to class C as per K&B, it shouldn't be accessible by the dot operator like that ._. this changes everything.


I don't know how you got to this conclusion -- as with the previous point, you somehow concluded that the dot operator won't work for protected, and now, you seem to imply that the dot operator won't work for private. It is perfectly fine to use the dot operator to dereference a private variable. It just has to be done by the same class or an inner class of that class.... This code compiles fine.



Henry
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

I believe my C++ parentage has crept up to me again...

Damn it. Thanks for debunking this confusion for me, Henry. I have to read this chapter again.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

In thinking about this a bit more, I am going to take a few steps back, and try to answer the original question from scratch....

Sanjeev Ba wrote:Once the subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass, with the exception of subclasses of the subclass.

1. What is its access level for subclasses of subclass
2. Does it have the same access level for subclasses of this subclass inside and outside the subclass's package.


The easiest way to think about accessibility is that "accessibility of a variable should not change when it is inherited".

In the example used in this topic, the variable "i" is declared as protected by the class A, and the class is in the package A. This means that the variable is accessible by any class in the A package, and by any class that subclasses (directly or indirectly) from the A class (regardless of what package it is in).

In the example, the B class subclasses the A class, so it inherits the "i" variable. And of course, it can access the "i" variable..... Now, remember that "accessibility of a variable should not change when it is inherited", so it should still *not* be accessible to any other classes in the B package (that does not subclass A). I think this is what K&B meant that it is private to the other classes in the subclass package.

However, remember, that "accessibility of a variable should not change when it is inherited", so the "i" variable should still be accessible by classes in the A package, even if it is using an instance of B.

The "responsible for the implementation of that object" rule applies, but let's leave that out for this question.

Sanjeev Ba wrote:
1. What is its access level for subclasses of subclass


Anyway, extrapolate this to class C, which is declared in the package C, and which subclass class B. Remember again, "accessibility of a variable should not change when it is inherited", so the variable "i" can be accessed by the class C. It also, can *not* be accessed by any other classes in the package C (that doesn't directly or indirectly subclass from A)..... and it still can be accessed by classes in the package A !!

Henry
Sanjeev Ba
Ranch Hand

Joined: Dec 31, 2006
Posts: 40

Ok, that answers my question. Thanks to both Henry and Pritish for your discussions.

I have learnt two important concepts.

1. Access level does not change upon inheritance.
2. 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.

I think Henry summarized it beautifully in the last post.

Thanks for your contributions guys.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Sanjeev Ba wrote:Ok, that answers my question. Thanks to both Henry and Pritish for your discussions.


No problem. The discussion was actually fun....

Oh, and BTW....

Henry Wong wrote:
The "responsible for the implementation of that object" rule applies, but let's leave that out for this question.


The reason it was left out, was because it actually wasn't important to the question. It was only mentioned to address a point that Pritish bought up.

And to summarize that....

1. "private" means private to the class, and not just to a particular instance. This means private variables can be accessed by other instances of the same class. It means that it can be accessed by code of the same class, such as static methods, or even methods of inner classes.

2. "protected" means protected to the class, and not just to a particular instance. The rules that apply for private access are similar to the rules that applies to protected access. The "responsible for the implementation of that object" rule seems to be the new (and odd) requirement here, but it makes sense.

3. "public" means public to the class, and not just to a particular instance. However, since there is really no noticeable difference between something that is public to all classes, or something that is public to code from all instances, this point actually doesn't matter much.

Henry
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

accoding to JLS

6.6.2 Details on protected Access

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.

Hi Henry, I'm not able to get this at all. now class B can access the protected variable 'i' of class A through inheritance. now in class B the access level of 'i' will be protected(as henry said accessibility cannot change with inheritance). now class C extends class B. let us apply "responsible for the implementation rule" here. now 'i' is the protected member of an object of class B. it can be access from outside the package only by code that is responsible for the implementation of THAT OBJECT i.e. B object. that is it should be IS -A B. but you said that it should be IS -A C.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

gurpeet singh wrote:Hi Henry, I'm not able to get this at all. now class B can access the protected variable 'i' of class A through inheritance. now in class B the access level of 'i' will be protected(as henry said accessibility cannot change with inheritance). now class C extends class B. let us apply "responsible for the implementation rule" here. now 'i' is the protected member of an object of class B. it can be access from outside the package only by code that is responsible for the implementation of THAT OBJECT i.e. B object. that is it should be IS -A B. but you said that it should be IS -A C.


Can you provide an example code that does this? ... meaning that you have code that is part of the C class that is trying to access an object that IS-A the B class -- and it works.

In this example, code from the C class trying to access an instance of B, will *not* compile. This will *not* compile.



Henry
Sanjeev Ba
Ranch Hand

Joined: Dec 31, 2006
Posts: 40

Henry,

In the example posted by Henry, class C belongs to a different package (pkg C) than class B.
So, protected member "i" of class B can be accessed in class C only via inheritance and therefore "b.i" will not compile, because it is accessing using instance var.

I think the question is, what is "THAT OBJECT". From the context it looks like "THAT OBJECT" is B.
But, "The code responsible for the implementation of that object" is class C.

But when in class C, we do

C c = new C();
System.out.print(c.i);

we are accessing the inherited member which really means C has a member "i" due to inheritance, which stated otherwise is "Code that is responsible for the implementation of that object.
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

Sanjeev Ba wrote:Henry,

In the example posted by Henry, class C belongs to a different package (pkg C) than class B.
So, protected member "i" of class B can be accessed in class C only via inheritance and therefore "b.i" will not compile, because it is accessing using instance var.

I think the question is, what is "THAT OBJECT". From the context it looks like "THAT OBJECT" is B.
But, "The code responsible for the implementation of that object" is class C.

But when in class C, we do

C c = new C();
System.out.print(c.i);

we are accessing the inherited member which really means C has a member "i" due to inheritance, which stated otherwise is "Code that is responsible for the implementation of that object.


yes that was exactly my confusion. and i did not get it. can somebody re-explain taking the example given above as context
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

Pritish Chakraborty wrote:I cannot try as I am not on the computer yet, but considering that the inherited 'i' variable acts like it is private to class C as per K&B, it shouldn't be accessible by the dot operator like that ._. this changes everything.

'Code that is responsible for the implementation of the object' - most vague gem of a JLS line I have heard all day!


you have misinterpreted what is written in the book. as per the book the protected member of a subclass becomes private to any code outside the subclass i.e. even if a class is in the same package as the subclass(the book called it neighbour) then it won't be able to access the protected variable and that it would be private for it. now here is the part which you left - the book also mentions "WITH THE EXCEPTION OF SUBCLASS OF SUBCLASS".
so that means subclass of the subclass will be able to access the protected variable. which also means accessibility does not change with inheritance.
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

So after this huge rant on JLS specs and what not, just to clarify, what can we conclude?

If I follow one inheritance tree, suppose of classes A->B->C regardless of what packages they are in, and A has a protected int member x, I can access x in B and C using instances of B and C respectively because - simply because protected means package+child level access.

So can I say that protected basically means that each class has a copy of the inherited member in its own space, in default-like fashion?

What I mean to say is, for eg, in class B, a (backed) copy of the member x is present. Backed means that if I change x in class A (using methods or otherwise), the change is reflected in the entire inheritance tree. And as this 'copy' of the member is present as B's own member, B can either access it through its own instance or as its own private variable (directly in its methods).

Am I right?
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

So can I say that protected basically means that each class has a copy of the inherited member in its own space, in default-like fashion?


in other parts you are correct. here you are wrong. each class does NOT have its own copy of inherited member. there is only ONE copy of members viz. in superclass. subclasses are able to access these members through superclass declaration. there is no COPYING.
Pritish Chakraborty
Ranch Hand

Joined: Jun 12, 2012
Posts: 91

Gurpeet, I mentioned 'backed copy' in the next line :P

Nevermind, why introduce ambiguity? Let's do away with the 'copy' word altogether.

Basically in an inheritance tree regardless of packages, a protected member at the top of the tree is available in default-like access for the rest of the tree.

This should end it.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

Pritish Chakraborty wrote:
Nevermind, why introduce ambiguity? Let's do away with the 'copy' word altogether.

Basically in an inheritance tree regardless of packages, a protected member at the top of the tree is available in default-like access for the rest of the tree.

This should end it.


This is true, except you may have to clarify that the default package access is only for the package for which the class where the variable has been declared. This means, assuming that the A, B, and C classes are in different packages, other classes that are not in the hierarchy tree, but in the same package as class A, can access the protected variable -- even if the instance is one of the subclasses.

Henry
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

gurpeet singh wrote:
you have misinterpreted what is written in the book. as per the book the protected member of a subclass becomes private to any code outside the subclass i.e. even if a class is in the same package as the subclass(the book called it neighbour) then it won't be able to access the protected variable and that it would be private for it. now here is the part which you left - the book also mentions "WITH THE EXCEPTION OF SUBCLASS OF SUBCLASS".
so that means subclass of the subclass will be able to access the protected variable. which also means accessibility does not change with inheritance.


Not sure what you are trying to say here.... but I think you are trying to say.... If class A and B are in the same package, and class A defines a protected variable, and class B subclass from class A, then other classes in the same package as A and B can only access the protected variable via an instance of A (but not of B). This is, of course, not correct. So, can you elaborate what you mean?

Henry
gurpeet singh
Ranch Hand

Joined: Apr 04, 2012
Posts: 924
    
    1

Henry Wong wrote:
gurpeet singh wrote:
you have misinterpreted what is written in the book. as per the book the protected member of a subclass becomes private to any code outside the subclass i.e. even if a class is in the same package as the subclass(the book called it neighbour) then it won't be able to access the protected variable and that it would be private for it. now here is the part which you left - the book also mentions "WITH THE EXCEPTION OF SUBCLASS OF SUBCLASS".
so that means subclass of the subclass will be able to access the protected variable. which also means accessibility does not change with inheritance.


Not sure what you are trying to say here.... but I think you are trying to say.... If class A and B are in the same package, and class A defines a protected variable, and class B subclass from class A, then other classes in the same package as A and B can only access the protected variable via an instance of A (but not of B). This is, of course, not correct. So, can you elaborate what you mean?

Henry


what i'm saying is that suppose i have class A in say com.example package which defines a protected variable . there is also class B which inherits from A and is in different package namely com.example1. now class B will be able to access the protected variable through inheritance(i think that is what the jls means by the implementation of that object). now suppose there is another class C in same package as B. this class C won't be ablet to access the protected variable inherited by class B. however the subclass of B will be able to access the protected variable(through inheritance). this is what i meant. actually there were some misunderstanding as to what is written in kb6 book in earlier posts, so i tried to correct that part.
sakthi vandhana
Greenhorn

Joined: Aug 08, 2013
Posts: 9
Sanjeev Ba wrote:Once the subclass-outside-the-package inherits the protected member, that member (as inherited by the subclass) becomes private to any code outside the subclass, with the exception of subclasses of the subclass.

1. What is its access level for subclasses of subclass
2. Does it have the same access level for subclasses of this subclass inside and outside the subclass's package.



package Ap;
public class A
{
protected int x = 100;
}

------------------

package Bp;
import Ap.A;

public class B extends A
{
}


----------------

package Cp;
import Bp.B;

class C extends B
{
void dispx()
{
System.out.println(x); // this works fine since x is treated as class C member
B b = new B(); // this works fine since class B is public and thus visible across package
System.out.println(b.x); // this doesnot compile since x has protected access in A
}
}

public class pra
{
public static void main(String args[])
{
C c = new C();
c.dispx();
}
}


--------------


Thanks
Ben Pheonix
Ranch Hand

Joined: Dec 11, 2012
Posts: 46
    
    1

Hi,
Please Usecodetags while posting a query.
Where are you confused in this? Outside a package a protected member can only be accessed through inheritance. You
Cannot use the parent class reference to access the protected member outside package.

Hth,
Ben


Twitter:ben_pheonix
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Protected access specifier.