# Understanding the Manifest

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

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


A specification of the manifest format is part of the on-line JDK documentation.
• 本文已收录于以下专栏：

## simple understanding of manifest

why manifest file exist? An assembly manifest is an XML file that describes a side-by-side assembly...
• u010125980
• 2015年02月13日 14:27
• 455

## CNN入门必读经典：Visualizing and Understanding Convolutional Networks

• bea_tree
• 2017年04月03日 12:55
• 1483

## 深度学习研究理解5：Visualizing and Understanding Convolutional Networks

Visualizing and understandingConvolutional Networks 本文是Matthew D.Zeiler 和Rob Fergus于（纽约大学）13年撰写的论文，主...
• whiteinblue
• 2015年01月30日 20:20
• 8654

## 《Understanding the difficulty of training deep feedforward neural networks》笔记

Sigmod为什么不适合深度学习，交叉熵代价函数和平方差代价函数，神经网络权重初始化...
• KangRoger
• 2017年03月11日 11:13
• 1240

## Visualizing and Understanding Convolutional Networks翻译总结

Zfnet 论文：《Visualizing and Understanding Convolutional Networks》 1.     概述 这篇论文主要的贡献是将卷及神经网络的隐藏层的特征进行...
• xjz18298268521
• 2016年08月31日 09:35
• 2353

## READING NOTE: Understanding Convolution for Semantic Segmentation

TITLE: Understanding Convolution for Semantic Segmentation
• joshua_1988
• 2017年03月04日 22:57
• 720

## 理解卷积Understanding Convolutions

In a previous post, we built up an understanding of convolutional neural networks, without referring...
• GarfieldEr007
• 2016年04月02日 13:47
• 1197

## Visualizing and Understanding Convolutional Networks(精读)

• shengno1
• 2014年11月12日 10:09
• 3870

## “看懂”卷积神经网(Visualizing and Understanding Convolutional Networks)

• kklots
• 2013年12月06日 18:15
• 17631

## 图像分割“Understanding Convolution for Semantic Segmentation”

• cv_family_z
• 2017年08月21日 16:39
• 486

举报原因： 您举报文章：Understanding the Manifest 色情 政治 抄袭 广告 招聘 骂人 其他 (最多只允许输入30个字)