What is the MANIFEST MF file in Java

Using the MANIFEST.MF file in Java

The contents of the manifest file in a JAR file created with version 1.0 of the Java Development Kit are as follows.

All entries are as name-value pairs. The name of a header is separated from its value by a colon. The standard manifest shows that it conforms to version 1.0 of the manifest specification. The manifest can also contain information about the other files packaged in the archive. Exactly what file information is recorded in the manifest depends on the intended use of the JAR file. The default manifest file makes no assumptions about what information to record about other files, so its single line only contains data about itself. Special-purpose manifest headers

Depending on the intended role of the JAR file, the default manifest may need to be changed. If the JAR file is created for archival purposes only, the MANIFEST.MF file will serve no purpose. Most uses of JAR files go beyond simple archiving and compression and require special information in the manifest file. The following are brief descriptions of the headers required for some specific JAR file functions

As JAR files bundled applications : When an application is bundled in a JAR file, the Java Virtual Machine must be informed of the entry point for the application. An entry point is a class with a public static void main method (String [] args). This information is provided in the main class header, which is of the general form:

Replace the class name value with the entry point of the application.

Download extensions: Download extensions are JAR files referenced by other JAR files' manifest files. In a typical situation, an applet is bundled into a JAR file, the manifest of which references a JAR file (or multiple JAR files) that serves as an extension for the purposes of this applet. Extensions can refer to each other in the same way. Download extensions are specified in the Classpath Header field in the manifest file of an applet, application, or other extension. For example, a classpath header could look like this:

With this header, the classes in the files servlet.jar, infobus.jar and acme / beans.jar serve as extensions for the purposes of the applet or the application. The URLs in the Class-Path header are specified relative to the URL of the applet's or application's JAR file.

Package sealing: A package in a JAR file can optionally be sealed. This means that all the classes defined in this package must be archived in the same JAR file. A package can be sealed to ensure version consistency between classes in your software or as a security measure. To seal a package, a name header must be added for the package followed by a sealed header similar to the following:

The value of the name header is the relative path name of the package. Note that it ends with a '/' to distinguish it from a file name. All headers that follow a name header, without any blank lines in between, apply to the file or package specified in the name header. In the example above, the sealed header is interpreted in such a way that it is (only) applied to the package myCompany / myPackage, since the sealed header comes after the header Name: myCompany / myPackage without any blank lines in between.

Package versioning: The package versioning specification defines several manifest headers that should contain version information. A set of such headers can be assigned to each packet. The version headings should appear just below the package name heading. This example shows all version headers: