File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes A protected access modifier problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "A protected access modifier problem" Watch "A protected access modifier problem" New topic

A protected access modifier problem

Peng Fan
Ranch Hand

Joined: May 04, 2004
Posts: 35
please first check out the following code:
package aaa;
class A{
protected int protectedVariable;
package bbb;
import aaa.A;
class B extends A{
public static void main(String[] args){
A a = new A();
B b = new B();
a.protectedVariable = 30;//illeage,but why?
b.protectedVariable = 30;//perfectly legal,and why?

we know protected modified methods and variables have both inheritance visibility(i am not sure whether this saying is suitable,if not please correct me) and package visibility,but what kind of principle does the above code illustrate. THX!
C. Nimo
Ranch Hand

Joined: Mar 23, 2004
Posts: 82
not sure what exactly you're asking but i'll do my best:
ok, so the protected variable has package+inheritance visibility.
this is why, if class bbb.B extends aaa.A - you can still have access
to the protectedVariable inside bbb.B, and manipulate it.
However, inside bbb.B, you are instantiating a class of type aaa.A. since
you are not in the same package, that means that you can only access the public parts of aaa.A.
What's a bit confusing, of course, is the fact that bbb.B extends aaa.A. This might lead to the conception that these classes are therfore very friendly, and that B could access all protected stuff in A. This, however, is not true when you have an object of type A inside B - when you have an object that's A. It's only true regarding the B object itself, and the protected stuff it inherited from A.
Peng Fan
Ranch Hand

Joined: May 04, 2004
Posts: 35
i still cannot make sense.i donot know why mr Gosling design such a mechanism,protected-modified stuff has inheritance visibility,in this case,bbb.B extends aaa.A, and i take it for granted that protectedVariable is visible in class B, so it's reasonable that this small bit of b.protectedVariable = 30; is feasible, however, to my surprise, a.protectedVariable = 30 is illegal,why?
i am willing to rigidly memorize this case.
Warren Dew
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
Why ... because the reason for inheritance of access to protected variables is to allow subclasses to reuse code, not to allow subclasses access to objects of the superclass.
When I'm writing the superclass A, I write some members that are safe for outsiders to mess around with. Since these are safe for outsiders to mess around with, I should make them public to maximize the usefulness of my class.
I also write some members that are not safe for outsiders to mess around with. Mostly these are private.
However, some of the latter members might be useful as building blocks for some subclass of A. The protected scope is designed to allow me to make some of my otherwise private members available for use in this way as building blocks. I trust whoever writes the subclass to use them safely in that subclass.
However, I'm still fully responsible for the safety of objects of concrete class A. If objects from a subclass could access protected members of these objects, I'd have to make the methods completely safe - and then they might as well be public members, rather than protected members. Or I'd just leave them private, denying the subclass the opportunity to reuse the code. In either case, the utility of the protected scope would be undermined, which is why it's not done that way.
Excellent question, by the way ... looks like you're looking for a real understanding of the principles behind the language.
Peng Fan
Ranch Hand

Joined: May 04, 2004
Posts: 35
thank you for your opinions, well, actually it seem that i just cannot extract much information that make me feel comfortable. Warren, what you said,maybe,gave me some hints that the reason for designing so-called protected access modifier is just force the client programmer to reuse the protected stuff other than access it through the superclass's instance,but this happens solely when super class and subclass are in different package respectively,say,if we put the superclass and subclass into a same package,in subclass the protected stuff defined in superclass can be accessed through a superclass's instance, under such circumstance,one of the functionalites(inheritance and package visibility) of protectd modifier
lost,just like package visibility having a higher priority than inheritance's, when the two exist simultaneously, package visibility just overcome the other. that's my you agree with me?
C. Nimo
Ranch Hand

Joined: Mar 23, 2004
Posts: 82
in my opinion, the point of protected access in real life is exactly to differentiate between the cases where you're writing code in a package, and when you're writing code outside a package.
lets say i need to write something that complies with an external api (like javax.jms). now - i can't add code to javax.jms, right? so i need to write my own classes (lets forget about javax.jms being a package of interfaces for a minute).
my javax.jms.Session implementation class needs to behave like the super javax.jms.Session class. so - in this case, a protected modifier for some of the variables inside javax.jms.Session can help a lot - I am not in the same package, yet - I can use this stuff, because I inherit from javax.jms.Session, effectively annoncing that i AM a javax.jms.Session myself. now, suppose i have a protected store of transacted messages - this is extremely fine with me.
However, when I am outside the package, and I do not declare myself to be of type javax.jms.Session - I can not access this protected store of messages. I can only use it via the public accessors methods. this is fine, because the notion of being a javax.jms.Session, or being on the same package with it - means that you have some reponsibility towards the protected items.
If I am on the same package as javax.jms.Session, it is legal for me to have access to that messages-store (and also - this could be quite effective and time comsuming) - but this is 'safe' - since i am accessing it from an affiliated (same-package) class.
your point about the superclass and subclass in the same package is different. suppose you have Super and then Sub.
now, if Sub extends Super, (same package or not) - and you have an object of type Sub - you can touch any of the protected items of this object. If you have an object of type Super inside the Sub - there's no precedence or anything. it's pretty simple - if both classes are inside the same package - you can have access to protected. if not - you can't, and it doesn't matter that you extend it.
I agree. Here's the link:
subject: A protected access modifier problem
jQuery in Action, 3rd edition