|
|
You can logically organize Java classes into packages. That means you can put all related classes into one package. For example, in our banking application, you decide to put all classes related to accounting in one package. A class defines the package it belongs to using the package statement. The format of the package declaration is:
package packageName;
The package name usually has a series of names separated by a period. By convention, it is the reverse domain name for the application. For example, if you are developing a Java application named “Reservation Application” for a company named aroundtheworld.com, then you may give com.aroundtheworld.reservations as the package name.
A package is the organizing mechanism for reducing the potential name conflicts in classes. To understand this better, let us assume that we have two applications, a banking application and a Library application and both these applications have a class named Account. In case of banking application, this class likely represents a banking account. Whereas in the library application, a class named Account is likely to be a library account. Now if both applications are running on the same Java platform, how will the runtime system differentiate between the two classes when somebody calls for class named Account? The solution is to use the package statement. Each of these two classes will state which package they belong in their declaration. For example, the Account class in banking application may declare that it belongs to a package com.mybank.accounting as:
package com.mybank.accounting;
public class Account{
// implement bank account here
}
The Account class in library application may declare that it belongs to another package as:
package com.mylibrary.catelog;
public class Account{
// implement library account here
}
Now Java environment can differentiate between the two classes with their fully qualified names as the com.mybank.accounting.Account class and the com.mylibrary.catelog.Account class and the naming conflict would be resolved.
Packages, sub-packages and compilation units
For better organization, a package has a hierarchical structure. It contains sub-packages and the compilation units (i.e the .Java files). The sub-package will further contain sub-packages and the compilation units and so on. The package’s name indicates these sub-packages, separating them by a period. In our library and banking applications, we have two package declarations. From that, we can conclude which packages, sub-packages and compilation units we have. Following are some of the conclusions:
The package com
is declared to have sub-packages mybank and mylibrary but no compilation units.
The package com.mybank has
a sub-package named accounting. This
sub-package com.mybank.accounting
will have the compilation unit for Account class.
Implementation of package and source code compilation
The syntax of package declaration is same for all Java platforms but how the packages, compilation units, and the sub-packages are created and stored depends on the different implementations of the platform. In simple Java implementations, the packages are stored on a local file system. In that case, all the packages, source and class files might be stored in a single directory and its subdirectories.
When a Java compiler reads a compilation unit, it produces one or more .class files. By default, the compiler puts each class file in the same directory as its source file. However, for better organization, you can specify the target directory while compiling. Now, the package declaration comes into picture. The compiler creates the directory structure as per the package declaration in .java file in this target directory. For example, assume that you are compiling a file named Account.java from the library application’s directory by specifying target directory as:
javac –d libraryapp/bin/ libraryapp/Account.java
When the Account.java is compiled, the compiler will
create the directory structure com/mylibrary/catelog in libraryapp/bin/ and the Account.class
file is stored in it. If you do not want to specify the target directory, you
should keep the .java files in a directory-tree that reflects their package tree.
For example, if you keep all your source files in \MyLibraryApp, the source code for Account class should be in \MyLibraryApp\com\mylibrary\catelog\Account.java.
By default, the compiler will put the class file in the same directory
as its source file after compilation.
The package declaration is optional in Java source file. If the package declaration is absent, the classes belong to the default un-named package after compilation. It means that if the .java file does not have the package declaration, the compiler creates the .class file in the default directory (which is the same directory as the source file). For small programs and casual development, a package can be unnamed or have a simple name, but if the code is to be distributed, you should give unique package names to avoid the name conflicts between classes.