Understanding the Manifest
JAR 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 ways manifests can be modified to enable special JAR-file functionality, let's take a look at the baseline default manifest.
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
META-INF/MANIFEST.MF
When a JAR file is created with version 1.2 of the JavaTM Development Kit, the default manifest file is very simple. Here are its full contents:
Manifest-Version: 1.0
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 JDKTM 1.1 default manifest file would look something like this:
Manifest-Version: 1.0
Name: java/math/BigDecimal.class
SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=
MD5-Digest: z6z8xPj2AW/Q9AkRSPF0cg==
Name: java/math/BigInteger.class
SHA1-Digest: oBmrvIkBnSxdNZzPh5iLyF0S+bE=
MD5-Digest: wFymhDKjNreNZ4AzDWWg1Q==
Like 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 java/math/BigDecimal.class.
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.
Special-Purpose Manifest Headers
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
Download extensions <!--
Hiding implementation classes in JAR files
-->
Applications Bundled as JAR Files - version 1.2 onlyIf 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:
Main-Class: classname
The value classname is the name of the class that is your application's entry point.
Download Extensions - version 1.2 onlyDownload 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. <!--
Hiding Implementation Classes in JAR Files - version 1.2 only
Your JAR file may contain packages that are part of your software's
implementation that aren't intended to be publically visible to other
applications. You can hide such packages by using the
Exported-Packages
header. When this header is used, only those packages listed as the
header's value will be visible outside the JAR file. For example:
Exported-Packages: com.ourcom.* com.mycom
specifies that the package com.mycom and all packages with
names beginning with com.ourcom will be visible outside the
JAR file. All other packages in the JAR file will be hidden.
If the manifest doesn't have an Exported-Packages header,
all packages are visible.
-->
Package Sealing - version 1.2 onlyA 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
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 myCompany/myPackage.
Package Versioning - version 1.2 onlyThe Package Versioning specification 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 Name header for the package. This example shows all the versioning headers:
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."
Additional Information
A specification of the manifest format is part of the on-line JDK documentation.
