A JAR file is the standard way Java code is packaged for distribution. Oracle’s JAR File Specification defines it plainly: a JAR file “is a file format based on the popular ZIP file format and is used for aggregating many files into one.” In practice this means a single JAR can hold dozens or thousands of compiled class files, along with images, configuration files, and other resources, all in one bundle that the Java runtime can load directly.
What distinguishes a JAR from an ordinary ZIP is the manifest. The specification notes that a JAR is “essentially a zip file that contains an optional META-INF directory,” and the key file in that directory is MANIFEST.MF. The manifest holds name-value pairs that describe the archive: attributes such as Manifest-Version, Created-By, Main-Class (which tells the runtime where to start an executable JAR), and Class-Path (which lists other libraries the JAR needs).
Because the JAR is a self-contained, named bundle, it became the natural unit for sharing Java libraries. When a build tool resolves a dependency, what it downloads is almost always a JAR. This is why JAR files sit at the center of the Java ecosystem’s package management: artifact repositories store them, build tools fetch them by name and version, and the JVM loads classes straight out of them at runtime.
The manifest can also carry per-entry attributes used for signing, such as digest values that let the runtime verify a JAR has not been tampered with. This gives the format a role not only in distribution but in establishing trust in the software supply chain for Java code.