jar — archives & manifests

Overview

jar builds and manipulates Java archives — zip files with a META-INF/MANIFEST.MF and conventions layered on top. The manifest is what turns a zip of classes into something the launcher, the module system and service loaders understand. Day to day the archives come out of Maven/Gradle, but the format's rules are worth knowing when a jar misbehaves.

Key points

• Operations: jar --create (-c), --extract (-x), --list (-t), --update (-u), always with -f file.jar; --describe-module (-d) prints a jar's module descriptor or automatic module name.
• MANIFEST.MF: Main-Class: makes java -jar work; Class-Path: adds space-separated relative jar paths to the classpath (widely misunderstood — it ignores absolute paths and -cp); Automatic-Module-Name: reserves a stable module name for pre-modular libraries.
• Executable jar: jar --create --file app.jar --main-class app.Main -C classes . writes the manifest entry for you.
• Multi-release jars (JEP 238): --release 17 places overriding class files under META-INF/versions/17/, letting one artifact carry version-specific implementations; Multi-Release: true is set in the manifest.
• Fat/shaded jars are not jar-tool features: bundling dependencies (Maven Shade, Gradle Shadow, Spring Boot's nested-jar layout) is a build-tool affair with its own pitfalls (merged META-INF/services, split packages).
• Reproducibility: --date normalises entry timestamps for reproducible builds.

Examples

jar --create --file app.jar --main-class app.Main -C build/classes .
jar --list --file app.jar
jar --describe-module --file lib/some-lib.jar

Related

• The JDK, the JRE & their tools — parent catalog of the toolchain.
• java launcher — java -jar consumes the manifest this tool writes.
• jmod — the module-native sibling format for jlink inputs.
• Build ecosystem — where fat jars, shading and artifact publishing actually happen.