Fundamentals (Docs)



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

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.

	import graphics.Rectangle;

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 

	import graphics.*;

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:

	import java.awt.*;
	import java.awt.color.*;

Name Ambiguities

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.

	Rectangle rect;

In such a situation, you have to use the member's fully qualified name.

	graphics.Rectangle rect;

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.