A package is a grouping of related types providing access protection and name space management.
Note that types refers to classes, interfaces, enumerations, and annotation types.
If you put multiple types in a single source file, only one can be public, and it must have the same name as the
source file. For example, you can define public class Circle in the file Circle.java.
If you do not use a package statement, your type ends up in an unnamed package. Generally speaking, an
unnamed package is only for small or temporary applications or when you are just beginning the development
process. Otherwise, classes and interfaces belong in named packages.
If you are trying to use a member from a different package and that package has not been imported, you must
use the member's fully qualified name, which includes the package name.
graphics.Rectangle myRect = new graphics.Rectangle();
To import a specific member into the current file, put an import statement at the beginning of the file before any
type definitions but after the package statement, if there is one.
Now you can refer to the Rectangle class by its simple name.
Rectangle myRectangle = new Rectangle();
To import all the types contained in a particular package, use the import statement with the asterisk (*) wildcard
For convenience, the Java compiler automatically imports three entire packages for each source file:
(1) the package with no name
(2) the java.lang package
(3) the current package
At first, packages appear to be hierarchical, but they are not. For example, the Java API includes many others
packages that begin with java.awt. However, the java.awt.color package, the java.awt.font package, etc are not
included in the java.awt package.
Importing java.awt.* imports all of the types in the java.awt package, but it does not import java.awt.color. If you
plan to use the classes and other types in java.awt.color as well as those in java.awt, you must import both
packages with all their files:
If a member in one package shares its name with a member in another package and both packages are imported,
you must refer to each member by its qualified name. For example, the graphics package defined a class named
Rectangle. The java.awt package also contains a Rectangle class. If both graphics and java.awt have been
imported, the following is ambiguous.
In such a situation, you have to use the member's fully qualified name.
Static Import Statement
There are situations where you need frequent access to static final fields (constants) and static methods from one
or two classes. Prefixing the name of these classes over and over can result in cluttered code. The static import
statement gives you a way to import the constants and static methods that you want to use so that you do not
need to prefix the name of their class.
The java.lang.Math class defines the PI constant and many static methods:
public static final double PI 3.141592653589793
public static double cos(double a)
Ordinarily, to use these objects from another class, you prefix the class name, as follows.
double r = Math.cos(Math.PI * theta);
You can use the static import statement to import the static members of java.lang.Math so that you don't need to
prefix the class name, Math.
import static java.lang.Math.*;
Once they have been imported, the static members can be used without qualification.
double r = cos(PI * theta);
Use static import very sparingly. Overusing static import can result in code that is difficult to read and maintain,
because readers of the code won't know which class defines a particular static object. Used properly, static
import makes code more readable by removing class name repetition.