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.
Baseline Default Manifest, 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
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 did not 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 Intervocening Blank Lines, You KNOW That The Digest Values Thei 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 is not in the JDK 1.2 default manifest -.. It is not 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 do not 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 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 there is your application's entry point.
Download Extensions - Version 1.2 OnlyDownload Extensions Are Jar Files That Are Reference 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.
Download Extensions Are Specified in The Class-Path Header Field in The Manifest File of 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 area 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 are not 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.ources * com.mycom
Specifies That The package
com.mycom and all packages with name, 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 CLASS IN YOURE.TO SEAL 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 File or Package Specified in
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. The Version 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.
