Comprehensive Guide to JAR Files, Manifest Specification, Signing, and Service Provider Configuration

JAR files are ZIP‑based archives used to bundle Java classes, resources, and optional META-INF directories; they can be created with the jar tool or the java.util.jar API and have no strict naming requirements.

The META-INF directory stores configuration files such as MANIFEST.MF , INDEX.LIST , signature files ( *.SF , *.DSA , *.RSA ) and service‑provider configuration files.

Manifest files consist of sections separated by blank lines; each section is a series of name: value header lines. Headers follow RFC822‑inspired syntax, support continuation lines, and must not exceed 65535 bytes.

section: *header +newline nonempty-section: +header +newline newline: CR LF | LF | CR (not followed by LF) header: name : value name: alphanum *headerchar value: SPACE *otherchar newline *continuation continuation: SPACE *otherchar newline alphanum: {A-Z}|{a-z}|{0-9} headerchar: alphanum | - | _ otherchar: any UTF‑8 character except NUL, CR and LF

The manifest is divided into a main section (containing global attributes such as Manifest-Version , Created-By , Signature-Version , Class-Path ) and one or more individual sections, each beginning with a Name: attribute that identifies a specific JAR entry.

Main attributes include version information, creator details, and optional security attributes. Individual sections describe per‑entry attributes; they may override main attributes and must include at least a digest attribute for signed JARs.

Typical main attributes: Manifest-Version: 1.0 Created-By: 1.7.0 (Sun Microsystems Inc.) Signature-Version: 1.0 Class-Path: servlet.jar infobus.jar acme/beans.jar images/

Per‑entry attributes can define content type, versioning, bean status, and signing information such as SHA-256-Digest , x-Digest-Manifest , and optional Magic keys that influence hash calculation.

Signature files ( .SF ) contain a main section with signer information and a list of per‑entry digests. Verification checks the signature on the .SF file, then validates manifest digests (both main‑section and per‑entry) using algorithms like SHA‑256 or SHA‑1.

Verification steps include: Validate the signature on the .SF file. If present, compare x-Digest-Manifest values with a computed manifest digest. If no manifest digest matches, fall back to validating x-Digest-Manifest-Main-Attributes and per‑entry digests. Validate each entry’s digest against the data referenced by its Name: attribute.

Signed JARs also contain binary signature blocks ( .RSA , .DSA ) that correspond to the .SF file.

The JAR Index ( INDEX.LIST ) optimizes class loading for network applets by mapping packages to the JARs that contain them, reducing the need to scan every archive. The file consists of sections with a JAR path header followed by a list of package or file names.

Service‑provider configuration files reside in META-INF/services . Each file is named after an abstract service class and lists concrete provider class names, one per line, using UTF‑8 encoding and ignoring comments prefixed by ‘#’.

Example provider configuration for a hypothetical java.io.spi.CharCodec service:

sun.io.StandardCodec # Standard codecs for the platform

Code that looks up a provider iterates over Service.providers(CharCodec.class) and returns the first non‑null encoder/decoder for a given encoding name.

The Class-Path attribute in a manifest can list relative URLs of dependent JARs or directories; the JVM resolves them relative to the code base of the containing JAR, adds them to the application class path, and eliminates duplicates.

Package sealing is controlled by the Sealed attribute, either globally in the main manifest or per package. A sealed package requires all its classes to be loaded from the same JAR, enhancing security and version consistency.

Overall, the specification defines how JAR files are structured, how manifests and signatures are formatted, how verification is performed, and how auxiliary mechanisms such as indexing, service loading, class‑path expansion, and package sealing contribute to reliable and secure Java deployment.