|Navigate Language Fundamentals topic: )|
If your application becomes quite big, you may have lots of classes. Although you can browse them in their alphabetic order, it becomes confusing. So your application classes can be sorted into packages.
A package is a name space that mainly contains classes and interfaces. For instance, the standard class
ArrayList is in the package
java.util. For this class,
java.util.ArrayList is called its fully qualified name because this syntax has no ambiguity. Classes in different packages can have the same name. For example, you have the two classes
java.sql.Date which are not the same. If no package is declared in a class, its package is the default package.
In a class, a package is declared at the top of the source code using the keyword
|Code listing 3.14: BusinessClass.java
If your class is declared in a package, say
business, your class must be placed in a subfolder called
business from the root of your application folder. This is how the compiler and the class loader find the Java files on the file system. You can declare your class in a subpackage, say
engine. So the full package is
business.engine and the class must be placed in a subsubfolder called
engine in the subfolder
business (not in a folder called
Import and class usageEdit
The simpliest way to use a class declared in a package is to prefix the class name with its package:
|Code section 3.88: Package declaration.
If you are using the class from a class in the same package, you don't have to specify the package. If another class with the same name exists in another package, it will use the local class.
The syntax above is a bit verbose. You can import the class by using the
import Java keyword at the top of the file and then only specify its name:
|Code listing 3.15: MyClass.java
Note that you can't import two classes with the same name in two different packages.
String belongs to the package
java.lang but they don't need to be imported as the
java.lang package is implicitly imported in all classes.
It is possible to import an entire package, using an asterisk:
|Code section 3.89: Wildcard imports.
While it may seem convenient, it may cause problems if you make a typographical error. For example, if you use the above import to use JFrame, but then type
JFraim frame = new JFraim();, the Java compiler will report an error similar to "Cannot find symbol: JFraim". Even though it seems as if it was imported, the compiler is giving the error report at the first mention of JFraim, which is half-way through your code, instead of the point where you imported JFrame along with everything else in javax.swing.
If you change this to
import javax.swing.JFraim; the error will be at the import instead of within your code.
Furthermore, if you
import javax.swing.*; and
import java.util.*;, and javax.swing.Queue is later added in a future version of Java, your code that uses Queue (java.util) will fail to compile. This particular example is fairly unlikely, but if you are working with non-Oracle libraries, it may be more likely to happen.
A package name should start with a lower character. This eases to distinguish a package from a class name. In some operating systems, the directory names are not case sensitive. So package names should be lowercase.
The Java package needs to be unique across Vendors to avoid name collisions. For that reason Vendors usually use their domain name in reverse order. That is guaranteed to be unique. For example a company called Your Company Inc., would use a package name something like this:
Importing packages from .jar filesEdit
If you are importing library packages or classes that reside in a
.jar file, you must ensure that the file is in the current classpath (both at compile- and execution-time). Apart from this requirement, importing these packages and classes is the same as if they were in their full, expanded, directory structure.
For example, to compile and run a class from a project's top directory (that contains the two directories
/libraries) you could use the following command:
$ javac -classpath libraries/lib.jar source/MainClass.java
And then to run it, similarly:
$ java -classpath libraries/lib.jar source/MainClass
The above is simplified, and demands that
MainClass be in the default package, or a package called
source, which isn't very desirable.
The runtime identity of a class in Java is defined by the fully qualified class name and its defining class loader. This means that the same class, loaded by two different class loaders, is seen by the Virtual Machine as two completely different types.