void method()

[Roedy Green]

... and its inner classes. Or is that what you mean with "inside
the body"?

they get complicated. See
http://mindprod.com/jgloss/nestedclasses.html

 

[Roedy Green]

So if a plain method (ie. void method()) is part of a class in the Sun JDK
it's basically private?

No. It is visible to all the classes in the package.

 

[Roedy Green]

Is a plain "void method()" public, protected or private by default?

Your question implies you have big hole in your knowledge. It will
take a long time to fill it by asking individual questions on a
newsgroup. Instead get a text book and read up on scope. Then ask
questions about what still does not make sense.

You can also read my more informal essays on scope.
Start at http://mindprod.com/jgloss/scope.html
and follow the links.

I recall wrestling with this long ago, doing experiments, and finally
deciding it was all trivial and obvious. Oddly, I have yet to figure
out a way to explain it all that makes its obviousness immediately
apparent.

Have faith that you will have some aha moments and you will wonder
what all the fuss as about.

Anonymous classes are another matter.

 

[Patricia Shanahan]

... and its inner classes. Or is that what you mean with "inside
the body"?

The exact statement in the JLS is: "Otherwise, if the member or
constructor is declared private, then access is permitted if and only if
it occurs within the body of the top level class (§7.6) that encloses
the declaration of the member or constructor."

I believe that is intended to include inner classes declarations.

Patricia

 

[Owen Jacobson]

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.

 

[Crouchez]

Your question implies you have big hole in your knowledge. It will
take a long time to fill it by asking individual questions on a
newsgroup. Instead get a text book and read up on scope. Then ask
questions about what still does not make sense.

You can also read my more informal essays on scope.
Start at http://mindprod.com/jgloss/scope.html
and follow the links.

I recall wrestling with this long ago, doing experiments, and finally
deciding it was all trivial and obvious. Oddly, I have yet to figure
out a way to explain it all that makes its obviousness immediately
apparent.

Have faith that you will have some aha moments and you will wonder
what all the fuss as about.

Anonymous classes are another matter.

Well the package private is barely ever used and I'd say 99% of methods have
a named access modifier

 

[Roedy Green]

Well the package private is barely ever used and I'd say 99% of methods have
a named access modifier

I think you are overgeneralising.

Consider a large but simple class like java.lang.String:
I counted 78 public, 4 default, 2 private..

Consider a more complicated class like java.util.Pattern, you see a
quite different distribution:
163 default, 69 private, 9 public.

Consider a simple standalone 1-class application, designed to do
work, rather than provide services to client:
8 private, 1 public.

Default is common when you have a complicated problem with mulitple
classes and lots of interaction between classes.

 

[Owen Jacobson]

http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html...

so it's basically private?

No; default ("package private", as mentioned elsewhere) access exists
independently of private access. There's a useful progression of
access levels:

'private' allows access from within the same top-level class.
default allows access from anywhere private allows access, as well as
to any other class in the same package.
'protected' allows access from anywhere default allows access, as well
as from any subclass.
'public' allows access from anywhere protected allows access, as well
as from anywhere else. (Ok, that one's a little contrived.)

For the java.lang.ThreadGroup class, other classes in java.lang are
allowed to manipulate its default-access members; since you can only
add classes to this package via vendor-specific trickery (and you
shouldn't do that), you can treat it as an implementation detail and
pretend it doesn't exist. On the other hand, you can use default
access in your own packages to allow closely-related classes (like a
container and its iterator) to directly access one another's members,
if that's the cleanest way to implement something.

 

[Adam Maass]

Is a plain "void method()" public, protected or private by default?

None of the above. It is 'default.' Its visibility is restricted to classes
in the current package, and subclasses in other packages.

-- Adam Maass

 

[Crouchez]

I've just released what package private actually is - it's the old basic
method (like in many old procedural languages) that didn't include method
security - limited to the working folder.

 

[Lew]

None of the above. It is 'default.'
True.

Its visibility is restricted to classes in the current package,

True. (Although "its own" would be a better adjective than "current".)

and subclasses in other packages.

False. That would require protected access.

 

[Roedy Green]

I've just released what package private actually is - it's the old basic
method (like in many old procedural languages) that didn't include method
security - limited to the working folder.

Learning Java is much like learning a foreign language. The sooner you
start learning to think in the language, rather than think in your
native language and translating, the better command of the language
you develop. This is even truer of Java than most other computer
languages because Java is so strongly idiomatic. There are canned
ways of doing almost everything. You build very little from scratch
from the primitive elements.