Editing JAR (file format) (section)

==Manifest==
A manifest file is a [[metadata]] file contained within a JAR.<ref>{{cite web|url=http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html |title=Understanding the Manifest |publisher=Java.sun.com |date=2003-03-21 |access-date=2012-07-31}}</ref><ref>{{cite web|url=http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#JAR%20Manifest |title=JAR File Specification |publisher=Download.oracle.com |access-date=2012-07-31}}</ref> It defines extension and package-related data. It contains [[name–value pair]]s organized in sections. If a JAR file is intended to be used as an executable file, the manifest file specifies the main class of the application. The manifest file is named <code>MANIFEST.MF</code>. The manifest directory has to be the first entry of the compressed archive.

===Specifications===
The manifest appears at the [[Canonical form|canonical]] location <code>META-INF/MANIFEST.MF</code>.<ref name="jarspec">{{cite web|url=https://docs.oracle.com/javase/10/docs/specs/jar/jar.html |title=JAR File Specification |publisher=Download.oracle.com |access-date=2012-07-31}}</ref> There can be only one manifest file in an archive and it must be at that location.

The content of the manifest file in a JAR file created with version 1.0 of the [[Java Development Kit]] is the following.

 Manifest-Version: 1.0

The name 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 contain information about the other files that are packaged in the archive. Manifest contents depend on the intended use 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. It should be encoded in UTF-8.

====Special-Purpose Manifest Headers====
JAR files created only for the purpose of archiving do not use the <code>MANIFEST.MF</code> file.

Most uses of JAR files go beyond simple archiving and compression and require special information in the manifest file.

===Features===
The manifest allows developers to define several useful features for their jars. Properties are specified in key-value pairs.

====Applications ====
If an application is contained in a JAR file, the [[Java virtual machine|Java Virtual Machine]] needs to know the application's entry point. An entry point is any class with a <code>public static void main(String[] args)</code> method. This information is provided in the manifest Main-Class header, which has the general form:

 Main-Class: com.example.MyClassName

In this example <code>com.example.MyClassName.main()</code> executes at  application launch.

====Package Sealing====
Optionally, a package within a JAR file can be sealed, which means that all classes defined in that package are archived in the same JAR file. A package might be sealed to ensure version consistency among the classes in the software or as a security measure.

To seal a package, a Name entry needs to appear, followed by a Sealed header, such as:
<syntaxhighlight lang="properties">
Name: myCompany/myPackage/
Sealed: true
</syntaxhighlight>
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 <code>Sealed</code> header occurs after the <code>Name: myCompany/myPackage</code> header with no intervening blank lines, the <code>Sealed</code> header applies (only) to the package <code>myCompany/myPackage</code>.

The feature of sealed packages is outmoded by the Java Platform Module System introduced in Java 9, in which modules cannot split packages.<ref name="JEP 261: Module System">{{cite web | url=https://openjdk.java.net/jeps/261 | title=JEP 261: Module System | access-date=2021-02-06}}</ref>

====Package Versioning====
Several manifest headers hold versioning information. One set of headers can be assigned to each package. The versioning headers appear directly beneath the Name header for the package. This example shows all the versioning headers:
<syntaxhighlight lang="properties">
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."
</syntaxhighlight>

====Multi-Release====
A jar can be optionally marked as a multi-release jar. Using the multi-release feature allows library developers to load different code depending on the version of the Java runtime.<ref name="JEP 238: Multi-Release JAR Files">{{cite web | url=https://openjdk.java.net/jeps/238 | title=JEP 238: Multi-Release JAR Files | access-date=2021-02-06}}</ref> This in turn allows developers to leverage new features without sacrificing compatibility.

A multi-release jar is enabled using the following declaration in the manifest:
<syntaxhighlight lang="properties">
Multi-Release: true
</syntaxhighlight>

====Dependencies====
The <code>MANIFEST.MF</code> file can be used to specify all the classes that must be loaded for an application to be able to run.<ref>the sun servlet specification, page 72 (servlet-2_4-fr-spec.pdf).  See also the [https://docs.oracle.com/javase/8/docs/technotes/tools/findingclasses.html Java Tech Notes].</ref>

Note that Class-Path entries are delimited with spaces, not with the system path delimiter:
<syntaxhighlight lang="properties">
Class-Path: . pkg1.jar path/to/pkg2.jar
</syntaxhighlight>