Re: void method()
On Nov 7, 8:36 am, lyallex <lyal...@gmail.com> wrote:
Crouchez wrote:
"Lew" <l...@lewscanon.com> wrote in message
news:No2dnUOFtuQ1VKzanZ2dnUVZ_g2dnZ2d@comcast.com...
Crouchez wrote:
So if a plain method (ie. void method()) is part of a class in the Sun
JDK
it's basically private?
There is no "basically private" access. There are four access levels, and
a
method or member's access is exactly one of the four, never "basically"
any of
them.
If a method (as in your example) is declared without any access modifier,
then
it has exactly package-private access. Not private. Private access means
accessible only to the class itself. Package-private is more exposed than
that; in addition, any class in the same package has access to it.
--
Lew
I know but what I am saying is if you write a 3rd party app and create a new
java.lang.ThreadGroup you can't use it's method "void add(Thread t)"
void add(Thread t) is a method in ThreadGroup that has default (or
package private) access. This mean that classes in java.lang can access
this method (because it is package private) however as you are unable to
'add' classes to the java.lang package you can't access this method
from your third party app. Actually in Eclipse you can write and compile
a class in the java.lang package but if you try to run it you get
java.lang.SecurityException: Prohibited package name: java.lang which is
interesting... gosh, it's been a while since I did the security thing.
Classes in packages starting with the string "java" can only be loaded
by the bootstrap classloader, which on Sun's JVM gets its classpath
from the -Xbootclasspath parameter (right now; subject to change
whenever Sun feels like it) and from the JVM's installation path.
This allows, for example, containers to provide implementations of
javax.servlet via the bootstrap classpath, even though that class is
neither part of the JRE library nor allowable from the default
classloader or its other children.