What is the difference in the accessibility of the following variables in Java?
public class Joe {
public int a;
protected int b;
private int b;
int c;
}
I'm most interested in what the last one is doing.
views:
938answers:
4
+7
A:
- public: read/writable for anyone
- protected: read/writable for instances of subclasses and from within the enclosing package
- private: read/writable for any instance of the class and inner or outer (enclosing) instance
- int c : package-private, read/writable for all classes inside same package
See the JLS for more details
EDIT: Added the comment for protected stating that access is granted from inside same package, you guys are totally right. Also added comment for private. I remember now... ;-)
dhiller
2008-11-06 06:06:54
I believe you are wrong about protected. In Java protected means package-private. It's the C# equivalent to internal
JaredPar
2008-11-06 06:48:50
No, he's absolutely _right_ about the protected and r/w for subclasses. dhiller even provided a link to the language spec where it is explained in detail.
boutta
2008-11-06 07:43:50
Read the spec more carefully, it denotes that the type of the instance must be a class or subclass. It makes no note of where the type instance is used from.
JaredPar
2008-11-06 07:50:44
A clearer explanation is available at javacamp http://www.javacamp.org/javavscsharp/access.html
JaredPar
2008-11-06 07:51:19
Actually, the third one isn't quite right either: private instance variables can be accessed by _any_ instance of that class.
Matthew Schinckel
2008-11-06 08:32:28
...which is what is said in the javacamp link : "Access limited to the containing type", not the containing instance.
Matthew Schinckel
2008-11-06 08:34:14
Protected variables (and methods) can be accessed from subclasses, but also from *any* other classes in the same package.
Leigh
2008-11-06 08:38:25
Yes, guys you are right!. I've added a comment to make that clear
dhiller
2008-11-06 11:02:28
A:
And all of these are compile time protections, they can be readily overridden through reflection at runtime.
Will Hartung
2008-11-06 06:22:59
+1
A:
I try to avoid package level access completely (the last access you mention).
I like to keep classes self-contained. If another class needs access to something in my class it should be public (and it should by a method, not an attribute). Otherwise I feel you've broken encapsulation, as explained in Abstraction VS Information Hiding VS Encapsulation.
VonC
2008-11-06 06:23:34
Sometimes package-private comes in handy for unit testing though. But basically I think you're right.
WMR
2008-11-06 06:35:48
@WMR: right, but it could be argued that unit testing could use Reflection to access private data or test protected/private methods... (if the SecurityManager allows it)
VonC
2008-11-06 07:23:27
Package-private should be the default for top-level classes and interfaces. The are certain rare situations where it is appropriate (in the absence of friends).
Tom Hawtin - tackline
2008-11-06 16:10:06
+1
A:
Sorry for answering corrections to one previous answer but I don't have enough reputation to modify directly...
- public - read/writable for anyone
- protected - read/writable for instances subclasses and all classes inside same package
- int c : package-private, read/writable for all classes inside same package
- private - read/writable for any member of that class itself and inner classes (if any)
It is better to order the access modifiers this way, from the broadest access (public) to the narrowest (private), knowing that when going from narrow to broad, you don't lose any possibilities.
That's particularly important for "protected", where it is often misunderstood that classes in the same package can also access protected members of a class (not only its subclasses).
jfpoilpret
2008-11-06 07:44:02