The JavaTM Tutorial

| Start of Tutorial > Start of Trail > Start of Lesson | Search Feedback Form

Trail: JAR Files
Lesson: Using JAR Files: The Basics

## 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
> - Package sealing
> - Package versioning

> ### 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:

> >     Main-Class: classname

> 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.

> ### Package Sealing - version 1.2 only

> 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

> 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 only

> The 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.

| Start of Tutorial > Start of Trail > Start of Lesson | Search Feedback Form