Packages
Navigate Language Fundamentals topic: ) |
If your application becomes quite big, you may have many 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.util.Date
and java.sql.Date
which are not the same. If no package is declared in a class, its package is the default package.
Package declaration
[edit | edit source]In a class, a package is declared at the top of the source code using the keyword package
:
Code listing 3.14: BusinessClass.java
package business;
public class BusinessClass {
}
|
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 business.engine
).
Import and class usage
[edit | edit source]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.
business.BusinessClass myBusinessClass = new business.BusinessClass();
|
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
import business.BusinessClass;
public class MyClass {
public static void main(String[] args) {
BusinessClass myBusinessClass = new BusinessClass();
}
}
|
Note that you can't import two classes with the same name in two different packages.
The classes Integer
and 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.
Wildcard imports
[edit | edit source]It is possible to import an entire package, using an asterisk:
Code section 3.89: Wildcard imports.
import javax.swing.*;
|
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.
Package convention
[edit | edit source]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: com.yourcompany.yourapplicationname.yourmodule.YourClass
.
Importing packages from .jar files
[edit | edit source]If you are importing library packages and 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.
Javac
[edit | edit source]For example, to compile and run a class from a project's top directory (that contains the two directories /source
and /libraries
) you could use the following command:
Compilation
$ javac -classpath libraries/lib.jar source/MainClass.java |
And then to run it, similarly:
Execution
$ 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.
BlueJ
[edit | edit source]With BlueJ just click on Tools, Preferences, Libraries, and add the .jar one by one.
Class loading/package
[edit | edit source]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.