TheJAR files can support a wide range of functionality, including electronic signing, version control, package sealing, extensions, and others. What gives JAR files the ability to be so versatile? The answer is embodied in the JAR file’s manifest.
The manifest is a special file that can contain information about the files packaged in a JAR file. By tailoring this “meta” information that the manifest contains, you enable the JAR file to be used for a variety of purposes.
Before looking at some of the manifests can be modified to enable special JAR-file functionality, let’s take a look at the baseline default manifest. When you create a JAR file, it automatically receives a default manifest file. There can be only one manifest file in an archive, and it always has the pathname
The Default Manifest
When you create a JAR file, it automatically receives a default manifest file. There can be only one manifest file in an archive, and it always has the pathname
When a JAR file is created with version 1.2 of the Java Development Kit, the default manifest file is very simple. Here are its full contents:
This line shows that a manifest’s entries take the form of “header: value” pairs. The name of a header is separated from its value by a colon. The default manifest shows that it conforms to version 1.0 of the manifest specification.
The manifest can also contain information about the other files that are packaged in the archive. Exactly what file information is recorded in the manifest will depend on what use you intend for the JAR file. The default manifest file makes no assumptions about what information it should record about other files, so its single line contains data only about itself.
The format of the default manifest file changed between versions 1.1 and 1.2 of the Java Development Kit. If you create a JAR file for the java.math package, for example, the JDK 1.1 default manifest file would look something like this:
ike the JDK 1.2 manifest file, the JDK 1.1 manifest has an entry for
Manifest-Version. The version number is the same, indicating that the manifest specification didn’t change between versions 1.1 and 1.2 of the JDK software.
Unlike the JDK 1.2 manifest file, the JDK 1.1 manifest has entries for each file contained in the archive, including the files’ pathnames and digest values. The pathnames are given as values of the
Name header. Any headers that immediately follow a
Name header without any intervening blank lines, pertain to the file specified by the
Name header. In the manifest above, for example, the first
Name header is followed by these lines:
SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64= MD5-Digest: z6z8xPj2AW/Q9AkRSPF0cg==
Because these lines follow the
Name header without any intervening blank lines, you know that the digest values they specify are the digest values for the file
Digest values are relevant only with respect to signing JAR files. In fact, that’s why the digest information isn’t in the JDK 1.2 default manifest — it isn’t always needed. To learn more about digests and signing, see the Signing and Authenticating JAR Files lesson.
Depending on what role you want your JAR file to play, you may need to modify the default manifest. If you’re interested only in the “ZIP-like” features of JAR files such as compression and archiving, you don’t have to worry about the manifest file. The manifest doesn’t really play a role in those situations.
Most uses of JAR files beyond simple archiving and compression require special information to be in the manifest file. Summarized below are brief descriptions of the headers that are required for some special-purpose JAR-file functions:
Applications bundled as JAR files
Applications Bundled as JAR Files – version 1.2 only
If you have an application bundled in a JAR file, you need some way to indicate which class within the JAR file is your application’s entry point. (Recall that the entry point is the class having a method with signature public static void main(String args).)
You provide this information with the Main-Class header, which has the general form:
The value classname is the name of the class that is your application’s entry point.
Download Extensions – version 1.2 only
Download extensions are JAR files that are referenced by the manifest files of other JAR files. See the trail on the extension mechanism for information about extensions.
In a typical situation, an applet will be bundled in a JAR file whose manifest references a JAR file (or several JAR files) that will serve as an extension for the purposes of that applet. Extensions may reference each other in the same way.
Download extensions are specified in the Class-Path header field in the manifest file of an applet, application, or another extension. A Class-Path header might look like this, for example:
Class-Path: servlet.jar infobus.jar acme/beans.jar
With this header, the classes in the files servlet.jar, infobus.jar, and acme/beans.jar will serve as extensions for purposes of the applet or application. The URLs in the Class-Path header are given relative to the URL of the JAR file of the applet or application. The
Name header’s value is the package’s relative pathname. Note that it ends with a ‘
/‘ to distinguish it from a filename. Any headers following a
Name header, without any intervening blank lines, apply to the file or package specified in the
Name header. In the above example, because the
Sealed header occurs after the
Name: myCompany/myPackage header, with no blank lines between, the
Sealed header will be interpreted as applying (only) to the package
A package within a JAR file can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software or as a security measure.
To seal a package, you need to add a
Name header for the package, followed by a
Sealed header, similar to this:
Name: myCompany/myPackage/ Sealed: true
<h4>Package Versioning - <em>version 1.2 only</em></h4> The <a href="http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html#PackageVersioning">Package Versioning specification</a> defines several manifest headers to hold versioning information. One set of such headers can be assigned to each package. The versioning headers should appear directly beneath the <code>Name</code> header for the package. This example shows all the versioning headers <pre>Name: java/util/ Specification-Title: "Java Utility Classes" Specification-Version: "1.2" Specification-Vendor: "Sun Microsystems, Inc.". Implementation-Title: "java.util" Implementation-Version: "build57" Implementation-Vendor: "Sun Microsystems, Inc."