*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Package Accessibility Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Package Accessibility" Watch "Package Accessibility" New topic
Author

Package Accessibility

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Assume Test is a directory. Under which we have two files.
Super.java and Sub.java
Super.java --> file name
//code starts
package Test;
public class Super
{
protected int x = 10;
}
//code ends
Sub.java --> file name
//code starts
import Test.Super;
class Sub extends Super
{
public static void main(String[] args)
{
Super s = new Sub();
System.out.println(s.i);
}
}
//code ends
Super.java compiles successfully and class file created.
While compiling Sub.java, following compile time error comes.
Can't access protected field i in Test.Super. Test.Super is not a
Sub class of current class.
System.out.println(s.i);
^
If you modify protected to public in Super.java for int i, it works good.
Please explain the above.
Bye,
cibhi.
Manali Rathi
Greenhorn

Joined: Aug 01, 2000
Posts: 6
Hi ..
I think the question is very tricky. Any how I tried to comile the code and it gives the same error. But the error message is a bit strange because it says
*Can't access protected field i in Test.Super. Test.Super is not a
Sub class of current class.*
which means it is trying to treat Test.Super as a subclass so I changed the code in Sub and now it is like this :
class Sub extends Test.Super{
public static void main(String[] args){
Sub s = new Sub();
System.out.println(s.x);}}
I have changed the line where you create the instance of Sub and the class type is Super.And it works fine.
this means in the original code it was treated as if we are trying to access the protected variable of Sub from Super which is not possible becase super is not a subclass of sub. and that was the message.
I understand it now. Hopefully you also got my point else try compiling the second version and you will get the meaning of it.
and one more correction change the variable to 'x' it is not 'i'

Savithri Devaraj
Ranch Hand

Joined: Jun 26, 2000
Posts: 103
Originally posted by prabha:
Assume Test is a directory. Under which we have two files.
Super.java and Sub.java
Super.java --> file name
//code starts
package Test;
public class Super
{
protected int x = 10;
}
//code ends
Sub.java --> file name
//code starts
import Test.Super;
class Sub extends Super
{
public static void main(String[] args)
{
Super s = new Sub();
System.out.println(s.i);
}
}
//code ends
Super.java compiles successfully and class file created.
While compiling Sub.java, following compile time error comes.
Can't access protected field i in Test.Super. Test.Super is not a
Sub class of current class.
System.out.println(s.i);
^
If you modify protected to public in Super.java for int i, it works good.
Please explain the above.
Bye,
cibhi.

prabha,
class Sub does not belong to package Test, it belongs to default package, so it cannot be under the Test directory. Try putting it in a different directory, and leaving the protected field protected.
Savithri
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1850
There is a definite difference between a "is a" and "has a" relationship. In a "has a" relationship one cannot access the protected fields of the class. However this can be done in a "is a" relationship which is nothing but inheritance. In the code below the class Sub has both "is a" and "has a" relationship with class Super. One should be able to distinguish where "is a " relationship exists and where "has a" relationship exists. One tends to think that Sub has only a "is a" relationship. This is where one makes a mistake.
Sometimes one uses a reference of a super class when creating a sub class. Though the Object of a sub class is created the reference is of type super. Variables in this case are not overriden like that of methods. The variables of the super class are only visible not that of the sub class (see example 2). Thus though there is a "has a relationship in this case variables that are protected are not visible and the compiler complains.
// file saved as Sub.java

Example 2

Regds.
Rahul
[This message has been edited by Rahul Mahindrakar (edited August 03, 2000).]
deekasha gunwant
Ranch Hand

Joined: May 06, 2000
Posts: 396
hi rahul,
in ur second example u've added just one field and the program gets compiled. how this addition of one field makes the program work i don't understand . please elaborate
regards
deekasha
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi Rahul,
Thanks for an right,excellent and prompt explanation. On the above i would like to add some more pints.
If subclass and superclass are in different package the super class protected variables are "available" in subclass due to inheritance ( is - a ) relationship. ( System.out.println(i) --> this will print the inherited super class protected variable's value since it is "available" at subclass).
If i made the super class variable as public that means i am making it more visible across the packages so it availabe to all classes.( has -a relations).(System.out.println(s.i) --> this will print the public ,superclass-variable value of different package or default,protected ,superclass-variable value of same package)

Thanks
Sekar.
Rajasekar Loganathan
Greenhorn

Joined: Aug 04, 2000
Posts: 5
Ra
Originally posted by Savithri Devaraj:
prabha,
class Sub does not belong to package Test, it belongs to default package, so it cannot be under the Test directory. Try putting it in a different directory, and leaving the protected field protected.
Savithri

Savithri it won't work even if it is in different
package say Super.java in p1 and Sub.java in package p2.
It all about modifiers. Both this means same ie they are
in different packages.
Bye
Sekar
Rahul Mahindrakar
Ranch Hand

Joined: Jul 28, 2000
Posts: 1850
Hi deekasha gunwant
sorry for being late. I have used the second example to demonstrate that there is no dynamic polymorphism for variables as in methods.
Regds.
Rahul.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Package Accessibility