public, or package-private (no explicit modifier).
 public, private, protected, 
 or package-private (no explicit modifier).
 
A class may be declared with the modifier public, in which case that class 
 is visible to all classes everywhere. If a class has no modifier (the default, also known 
 as package-private), it is visible only within its own package (packages are named groups of 
 related classes—you will learn about them in a later 
lesson.) 
 
 At the member level, you can also use the public modifier or no modifier (package-private) 
 just as with top-level classes, and with the same meaning. For members, there are two additional 
 access modifiers: private and protected. 
 The private modifier specifies that the member can only be accessed in its own class. 
 The protected modifier specifies that the member can only 
 be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.  
 
The following table shows the access to members permitted by each modifier.
| Modifier | Class | Package | Subclass | World | 
|---|---|---|---|---|
| public | Y | Y | Y | Y | 
| protected | Y | Y | Y | N | 
| no modifier | Y | Y | N | N | 
| private | Y | N | N | N | 
Access levels affect you in two ways. First, when you use classes that come from another source, such as the classes in the Java platform, access levels determine which members of those classes your own classes can use. Second, when you write a class, you need to decide what access level every member variable and every method in your class should have.
Let's look at a collection of classes and see how access levels affect visibility. The following figure shows the four classes in this example and how they are related.

Classes and Packages of the Example Used to Illustrate Access Levels
| Modifier | Alpha | Beta | Alphasub | Gamma | 
|---|---|---|---|---|
| public | Y | Y | Y | Y | 
| protected | Y | Y | Y | N | 
| no modifier | Y | Y | N | N | 
| private | Y | N | N | N | 
private unless you have a good
reason not to.
public fields except for constants. 
(Many of the examples in the 
tutorial 
use public fields.
This may help to illustrate some points concisely, but is not
recommended for production code.)
Public fields tend to link you to a particular implementation
and limit your flexibility in changing your code.