Packaging and Deployment: JAR and WAR

Once a Java application is written and tested, it needs to be packaged into a distributable form that can run on another machine — a teammate's laptop, a test server, or production infrastructure. Java defines standard archive formats for this, and the two you'll encounter constantly are JAR (Java ARchive) and WAR (Web ARchive).

Both are, structurally, just ZIP files with a specific internal layout and a required metadata file. The difference is what they're meant to contain and where they're meant to run.

Why it matters

Compiled classes are not what you hand to a server; an archive is. Knowing what is inside a JAR or a WAR, and what makes one runnable, explains the errors met on every first deployment: "no main manifest attribute" and ClassNotFoundException. Spring Boot's single runnable JAR builds directly on these ideas.

JAR — Java ARchive

A JAR bundles compiled .class files, resources (property files, images, config), and a manifest file (META-INF/MANIFEST.MF) into a single distributable file. JARs are used both for reusable libraries (something other projects depend on, with no way to "run" it directly) and for standalone runnable applications.

• A library JAR is meant to be placed on another program's classpath or declared as a Maven/Gradle dependency.
• A runnable JAR includes a Main-Class entry in its manifest, so it can be executed directly with java -jar app.jar without specifying the entry class on the command line.
• A "fat" or "uber" JAR bundles the application's own classes together with all of its dependencies' classes, so it can run standalone with no external classpath setup.

WAR — Web ARchive

A WAR packages a Java web application — servlets, JSPs, static assets, and web-specific configuration (WEB-INF/web.xml or its modern annotation-based equivalent) — in a structure that a servlet container understands. Unlike a plain JAR, a WAR is not run with java -jar; it is deployed into a servlet container such as Apache Tomcat, Jetty, or WildFly, which unpacks it, wires up the servlets, and manages the application's web lifecycle (handling HTTP requests, session management, and so on).

Choosing Between Them

The choice generally isn't really a choice you make freely — it follows from the architecture. A command-line tool, a batch job, a microservice with an embedded HTTP server (such as one built with embedded Tomcat inside Spring Boot), or a shared library is packaged as a JAR. A traditional web application meant to be deployed into an externally managed servlet container is packaged as a WAR. Modern cloud-native Java increasingly favors runnable "fat" JARs with an embedded server over WARs deployed to a separate container, because it simplifies deployment to a single self-contained artifact.

Examples

// Compile
// javac -d out src/com/webnest/App.java

package com.webnest;

public class App {
    public static void main(String[] args) {
        System.out.println("Running from a JAR file");
    }
}

// Create a manifest file, manifest.txt, containing:
// Main-Class: com.webnest.App
//
// Package into a runnable JAR:
// jar cfm app.jar manifest.txt -C out .
//
// Run it directly, no classpath flags needed:
// java -jar app.jar

Running from a JAR file

my-webapp.war
├── index.html
├── css/
│   └── styles.css
└── WEB-INF/
    ├── web.xml                 (servlet mappings, or omitted if using annotations)
    ├── classes/
    │   └── com/webnest/HelloServlet.class
    └── lib/
        └── some-dependency.jar

// Deployed by copying my-webapp.war into Tomcat's webapps/ directory.
// Tomcat unpacks it and serves it at: http://localhost:8080/my-webapp/

INFO: Deploying web application archive [my-webapp.war]
INFO: Deployment of web application archive [my-webapp.war] has finished

Exercise

This exercise uses the JDK command-line tools in a terminal, so it does not run in the playground. A project has one source file, src/Main.java, whose class Main has a main method. Write the commands that compile it into the folder out, package the compiled classes into app.jar with Main as the entry point, and run the JAR.

Expected result: the last command runs the program, with no "no main manifest attribute" error.

# TODO: compile src/Main.java into the folder out

# TODO: create app.jar with Main as the entry point, from the contents of out

# TODO: run the JAR

javac -d out src/Main.java

jar cfe app.jar Main -C out .

java -jar app.jar

Quick quiz

Interview questions