It's not a secret anymore!*
The moose likes Java in General and the fly likes Access Control: Why am I unable to access this protected member from a subclass in another package? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Access Control: Why am I unable to access this protected member from a subclass in another package?" Watch "Access Control: Why am I unable to access this protected member from a subclass in another package?" New topic
Author

Access Control: Why am I unable to access this protected member from a subclass in another package?

Wout Er
Greenhorn

Joined: Nov 26, 2012
Posts: 15
Hi,

I'm experimenting with Access Controls and up till now observed three ways in which private or protected members can be accessed:
1. From a piece of code having access, through the 'this' reference (implicitly: w/o mentioning it).
2. From a piece of code having access, through the 'this' reference (explicitly)
3. From a piece of code having access, through a non-this reference of the containing class' type

This works for private and protected (if the subclass is in the same package), but apparently method #3 doesn't work for protected members accessed from a subclass within a different package.
More specifically, this doesn't work:





Since method #3 works for private members and protected members within the same package (and it's actually useful, for instance in the equals(Object) implementation), I'm wondering why it's not working for protected members accessed from a subclass within a different package? Anyone knows the rationale behind this?

Thanks!
H. J. Yoshi
Greenhorn

Joined: Jul 21, 2006
Posts: 29
That's protected at work.

It gives the subclass in a different package access to the member through inheritance. The protected member can not be accessed as if it were a public member.

Hence in your example:



If you think about it - that is, actually, how it is "protected" from other objects by disallowing invocation of doProtectedThings() using the Roo object and only letting the inherited classes have access to it.

Hope that helps.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38007
    
  22
Welcome to the Ranch
You would do well to read the theory behind access control, too. Here it is. Simplified version. You will see it goes on about the implementation of that type. The methods of an object of a subclass of your type are responsible for its implementation. The static methods do not constitute part of an object, so they don’t count as responsible for etc.

At least I think that is what is happening. I have never been 100% certain about protected access.
Wout Er
Greenhorn

Joined: Nov 26, 2012
Posts: 15
Thanks for the links Ritchie. I've seen the simplified version of the docs before, and I'll check the more detailed version when I have the time :-).
I know the access issue is due to the protected access modifier. I'm just wondering about the rationale behind this design decision, since I think it's strange to allow classes in the same package to do the access on a non-this reference, but allowing subclasses in another package not to...
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18529
    
  40

Wout Er wrote:Thanks for the links Ritchie. I've seen the simplified version of the docs before, and I'll check the more detailed version when I have the time :-).
I know the access issue is due to the protected access modifier. I'm just wondering about the rationale behind this design decision, since I think it's strange to allow classes in the same package to do the access on a non-this reference, but allowing subclasses in another package not to...



Two points...

First, keep in mind that there are four access levels -- not three. The four access levels (from most restrictive to least restrictive) are private, default, protected, and public. The default level allows classes within the same package to access each other. And the protected access level is less restrictive than the default level -- if the protected level allows subclass to access, but don't allow the classes in the same package to access, then arguably it is weirder (as defalt and protected are both between private and public, but it won't be clear which is more or less restrictive).

Second, and probably the main reason for your confusion, subclasses outside of the package can access a protected resource -- it make little sense that it can't... but to do so, it has to be "responsible" for the code. So, in your code example, if the variable had been a Boo instance (and reference), then it would have been allowed to access the protected resource defined by the Roo class.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Wout Er
Greenhorn

Joined: Nov 26, 2012
Posts: 15
Henry Wong wrote:
if the variable had been a Boo instance (and reference), then it would have been allowed to access the protected resource defined by the Roo class.


Henry, thanks for pointing this out and luckily this works! Still, I don't see the rationale for why it doesn't work on a Roo-typed reference within subclass code in another package, while it does within any code in the same package.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18529
    
  40

Wout Er wrote:Henry, thanks for pointing this out and luckily this works! Still, I don't see the rationale for why it doesn't work on a Roo-typed reference within subclass code in another package, while it does within any code in the same package.



Don't know what more to tell you, except that the "same package" distiction is clearly mentioned in section 6.6.1 of the specifcation -- which I presume is so that it can be less restrictive than the default access.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6.1

And the "responsible for the code" requirement, which triggers the "doesn't work" portion of your test, is clearly mentioned in section 6.6.2.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#jls-6.6.2

Anything more at this point, would be speculation on my part.

Henry
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
Wout Er wrote:
Henry Wong wrote:
if the variable had been a Boo instance (and reference), then it would have been allowed to access the protected resource defined by the Roo class.


Henry, thanks for pointing this out and luckily this works! Still, I don't see the rationale for why it doesn't work on a Roo-typed reference within subclass code in another package, while it does within any code in the same package.




Ok, probably you can think of a hypothesis like this. What difference does it make if these 2 lines of code were in package b or package c or package d OR within class Boo(subclass) or any class Foo(not subclass)? There is no absolutely no difference.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Access Control: Why am I unable to access this protected member from a subclass in another package?
 
Similar Threads
New Doubt: from SCJP6.0 K&B MockExam-1
Accessing protected method
Declaration and Access Control
confusion of protected
about package