why iam able to access defualt specifier field even within a sub-class ?

[Vinod Vinu]

There are three classes :-

Base.java

 /**
*
*/
package example.fun;
/**
* @author vk185052
*
*/
public class Base {
private String fName;
public String mName;
protected String lName;
String address;
}

Derived.java

 /**
*
*/
package example.fun;
/**
* @author vk185052
*
*/
public class Derived extends Base{
private void display(){
Base base=new Base();
base.mName="Public";
base.lName="protected thru sub-class";
base.address="default thru sub-class";
}
}

New.java

 /**
*
*/
package example.fun;
/**
* @author vk185052
*
*/
public class New {
/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
Base base = new Base();
base.mName="Public";
base.lName="Protected thru another but not sub-class means same Package";
base.address="Default same Package";
}
}

I know that the Protected access specifier fields can be accessed within same class, sub-class and same package and defualt access specifier fields can be accessed withing same class, and same package only.
But why i'm able to acess the default specifier fields with sub-class also ? (see the screen shot attached)
Am i doing something wrong here ? please tell me, it is very important to clear this basic.

[Christophe Verré]

 

But why i'm able to acess the default specifier fields with sub-class also ?

If I were you, I'd wonder what would happen if the subclasses were in a different package than their parent.

[Seetharaman Venkatasamy]

indicate which line you are facing problem. your code looks fine to me. more over, I dont find any information from your attachment.

[Ninad Kuchekar]

 

Vinod Vijay wrote: .....defualt access specifier fields can be accessed withing same class, and same package only.

I think you have already answered your question.

[Vinod Vinu]

 

indicate which line you are facing problem. your code looks fine to me. more over, I dont find any information from your attachment.

 base.address="default thru sub-class"; 

see this line, i'm able to read it very easily in the Derived class

[Christophe Verré]

Also, your example doesn't illustrate what you are trying to check. In Derived#display, you shouldn't have Base base=new Base(); You should have :

public class Derived extends Base{
private void display() {
mName="Public";
lName="protected thru sub-class";
address="default thru sub-class";
}
}

[Vinod Vinu]

hi Christophe Verré , i have got your point that

If I were you, I'd wonder what would happen if the subclasses were in a different package than their parent.

i tried with another class found that default fields cannot be accessed from a sub-class(residing in a different package that of its parent class) but can be accessed withtin a sub-class if both parent and child are in same package only.

Now my next question is then what is difference between Protected and Default. Don't you think so that both are behaving similarly ?

[Stephan van Hulst]

Protected and default access have to very different purposes.

You need to understand how important the notion is that a class member can be accessed outside of a package. Default access makes a member visible to any class that is inside the same package *only*.
Protected access means that the member can be accessed outside of the package, even if it is only by subclasses. This difference is very great.

Think of a package as something that is yours. If there is something inside this package that the rest of the world can't see, then it will make it very easy for you to change this thing later on.
However, if there is something in your package that is either public or protected, then the rest of the world can see it, and it can write code that depends on it. From this point on you have a commitment to never change what this piece of your package does, or it will break the code of someone else who depends on it.

I believe that you should almost always favour composition over inheritance. I declare all my classes final, unless I design them explicitly to be extended.
In practice, for now I would suggest going by my rule of thumb:

Use private and default access as you please. You can never go wrong with them.
Never use protected. You need to have a very clear idea of what you are designing if you are going to need protected access.
Use public sparingly. Only if the outside world needs access to a piece of your package.

If you want a great example of good use of protected, take a look at FilterInputStream and all its subclasses. These classes were designed to be inherited, and are clearly documented.

[Vinod Vinu]

thanks Stephan van Hulst