• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

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
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic