Java JAR Files & Packages

As Java systems and the resources the rely on become larger and more complex, managing the various files that comprise them becomes more difficult. Two related concepts -- and associated tools and techniques -- that are heavily relied on to help manage complexity are Java JARs and Packages.

JAR Files: Concept

JARs are a special form of Zip compressed file. They allow the Java a programmer to group a set of related classes into a single file that can be copied, moved, and/or passed around the network. One particularly noteworthy instance of this is downloading the files associated with an applet. If the files are contained "loose" within a directory, each is loaded separately and each requires a round trip between client/browser and server. However, if several applet-related files are gathered into a jar file, the entire jar file is loaded in a single fetch.

JAR files allow each file contained within them to be identified, and they retain any inherent relationships that exist among the files, such as inclusion in several levels of hierarchical directories. Thus, for example, one might have a directory structure such as the following:
Project
  applets
    ui.class
    addressbookfacade.class
    communicator.class
  servlets
    controlservlet.class
    listenserver.class
    handleserver.class
    adddressbook.class
One can gather all of the files in the Project into a single jar file, or one can build two jar files -- one for the classes under the applets directory and one for the classes under the servlets directory.

To understand jar files, one must also understand Java Packages.

Packages

Java packages play both a practical and a more abstract or theoretical role in Java system development. One of their most important functions is providing control over the namespace of Java classes. it's easy to imagine that two different programmers working on the same project might use the same name for two different classes, such as ErrorMessage or UserParameters. If both were using the same (extensive) CLASSPATH setting, references to such classes would be ambiguous. The Java compiler or loader would be happy so long as it could find one of them, but it might not be the class the programmer intended.

Java package names provide one solution to this problem. They allow the programmer to specify that a specified set of classes is to be identified with a hierarchical name, such as edu.jbs.ooc.ui or edu.jbs.ooc.beans. Then, any class included in the package can unambiguously be referred to as edu.jbs.ooc.ui.UserParameters or com.xyz.bigproject.UserParameters. It's a bit long-winded, but there would be no confusing the two versions of the class, UserParameters.

Packages and JAR files are often related. One may create a jar file for a single package. But such is not required. Frequently, classes from several packages are gathered and stored within a single jar file. However, if this is done, one must be careful to preserve within the jar the hierarchical name of each class as it is designated in its respective package.

Packages: Implementation

Implementation of a package is very easy. One simply includes the hierarchical name of the package along with the keyword, package, as the first statement in a program. For example:
package edu.jbs.ooc.ui;

import java.net.*;
import java.io.*;
import java.sql.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

import com.ibm.ejs.ns.jndi.*;
import javax.naming.*;
import javax.ejb.*;

import com.oreilly.servlet.multipart.*;

public class UIServlet extends javax.servlet.http.HttpServlet {
In some other program, if the edu.jbs.ooc.ui package had been imported, UIServlet could be referred by that name alone so long as it was unambiguous. But it could also be referred to as edu.jbs.ooc.ui.UIServlet if there was any question of the particular class.

Another implication of package is the additional scope parameter protected, to go along with public and private. As one may recall, public methods (and variables) can be referenced from any object that can "see" the object in which they are defined. Private methods and variables can only be referenced from within the class where they are defined. Protected methods and variables fall somewhere in-between -- namely, they can be referenced from any object whose class is within the same package.

JAR: Implementation

Jar files can be created automatically by many Java development environments. However, the JDK/SDK distributions also include a jar management tool, called not surprisingly jar. Review the documentation, paying particular attention to the basic syntax of the command.

Two basic forms of the command that are likely to be used rather often are:
    jar cf MyJarFile.jar *.class
    
and
    jar uf MyJarFile.jar anotherclass.class
    
The first creates a new jar file, MyJarFile.jar, from all of the .class files in the current directory. If MyJarFile.jar exists, it is overwritten.

The second adds an additional file -- anotherclass.class -- to an existing jar file, updating it but not destroying the original.

If the files are included within several layers of directories, they may all be included by referring simply to the directory name. However, one must be cautious that the directory structure reflects the package (hierarchical) name for the files since they will be accessible from within the jar file by the concatenated names of the directories. For example, look at the following directory.

Applet Reference

The files in the jar file can then be referenced through the applet tag:
<applet code=myApplet.class codebase=path/to/code/directory archive=MyJarFile.jar >
</applet>