WAR vs JAR Files

What are JAR and WAR — and Why Package at All?

A compiled Java application is, physically, hundreds of separate .class files plus resources plus configuration — none of that is anything you'd want to copy file-by-file to a server or hand to a container runtime. A JAR (Java Archive) is a ZIP file with a Java-specific structure and metadata that lets the JVM run code directly from it; a WAR (Web Application Archive) is a JAR with an additional, standardized directory layout that a servlet container (covered on the previous two pages) knows how to unpack and deploy as a running web application.

// BEFORE — deploying an application as loose files
$ scp -r target/classes/ user@server:/opt/myapp/
$ scp -r target/dependency/ user@server:/opt/myapp/lib/
$ ssh user@server "cd /opt/myapp && java -cp classes:lib/* com.shop.Main"
// Every file transferred individually, no single artifact to version, no
// manifest describing what this even is or how to run it correctly

// AFTER — one artifact, self-describing, single command to run
$ scp target/myapp.jar user@server:/opt/myapp/
$ ssh user@server "java -jar /opt/myapp/myapp.jar"
// One file. The manifest inside it already declares the entry point —
// java -jar reads META-INF/MANIFEST.MF to find Main-Class automatically.

# A JAR/WAR is a real ZIP file underneath — this always works:
unzip myapp.jar -d extracted/
jar -tf myapp.jar        # list contents
jar -xf myapp.jar        # extract contents

JAR Files — Structure and the Manifest

myapp.jar
├── META-INF/
│   └── MANIFEST.MF          # metadata: entry point, classpath, version
├── com/shop/
│   ├── Main.class
│   ├── ProductService.class
│   └── util/Helper.class
├── application.properties
└── static/logo.png

# META-INF/MANIFEST.MF
Manifest-Version: 1.0
Main-Class: com.shop.Main
Class-Path: lib/gson-2.9.0.jar lib/commons-lang3-3.12.0.jar
Implementation-Title: Shop Catalog Service
Implementation-Version: 1.0.0

Fat JARs — Two Genuinely Different Mechanisms Behind the Same Word

"Fat JAR" gets used as if it describes one technique. It doesn't — the two common approaches produce structurally different artifacts, and confusing them is a real source of production bugs, not just terminology pedantry.

Maven Shade — flattens everything into one namespace

<!-- pom.xml -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
        <execution>
            <phase>package</phase>
            <goals><goal>shade</goal></goals>
        </execution>
    </executions>
</plugin>
// Every dependency's .class files are extracted and merged directly into
// ONE flat package namespace inside the final JAR — as if you'd manually
// unzipped every dependency JAR into the same directory.

Spring Boot repackage — nested JARs, not a flattened merge

<!-- pom.xml — this is what spring-boot-starter-parent wires up by default -->
<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals><goal>repackage</goal></goals>
        </execution>
    </executions>
</plugin>

// The resulting structure is deliberately NOT flattened:
myapp.jar
├── org/springframework/boot/loader/   # Spring Boot's own bootstrap classloader
├── BOOT-INF/classes/                  # YOUR compiled classes, untouched
└── BOOT-INF/lib/                      # every dependency, as WHOLE, UNMODIFIED jars
    ├── spring-web-6.1.0.jar
    ├── gson-2.9.0.jar
    └── ...

WAR Files — Structure and the WEB-INF Boundary

mywebapp.war
├── META-INF/
│   └── MANIFEST.MF
├── WEB-INF/                    # PROTECTED — never served directly over HTTP
│   ├── web.xml                 # deployment descriptor
│   ├── classes/com/shop/ProductServlet.class
│   └── lib/gson-2.9.0.jar, mysql-connector-8.0.jar
├── index.html                  # PUBLIC — /mywebapp/index.html
└── css/style.css                # PUBLIC — /mywebapp/css/style.css

# Reachable directly:
http://localhost:8080/mywebapp/index.html        ✓
http://localhost:8080/mywebapp/css/style.css     ✓

# NEVER reachable directly — the container itself refuses to serve it:
http://localhost:8080/mywebapp/WEB-INF/web.xml   ✗ 404
http://localhost:8080/mywebapp/WEB-INF/classes/  ✗ 404

# This is enforced by the servlet specification itself, not a configurable
# option — every compliant container treats WEB-INF/ as off-limits to direct
# requests. That's precisely why compiled code, configuration with database
# credentials, and dependency JARs all belong inside it.

<!-- pom.xml -->
<packaging>war</packaging>
<dependencies>
    <dependency>
        <groupId>jakarta.servlet</groupId>
        <artifactId>jakarta.servlet-api</artifactId>
        <version>6.0.0</version>
        <scope>provided</scope>   <!-- the container supplies this — never bundle it -->
    </dependency>
</dependencies>

JAR vs WAR — Side by Side

Spring Boot: JAR or WAR?

JAR — the default, recommended path

<packaging>jar</packaging>
# java -jar myapp-1.0.0.jar — embedded Tomcat included, no external
# container to install or configure, natural fit for a Docker image

WAR — only when an external container is a hard requirement

<packaging>war</packaging>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <scope>provided</scope>   <!-- the target container supplies its own Tomcat -->
</dependency>

@SpringBootApplication
public class ShopApplication extends SpringBootServletInitializer {
    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder app) {
        return app.sources(ShopApplication.class);
        // This bridge is what lets the SAME application also start correctly
        // when deployed as a WAR to an external Tomcat, which calls this
        // instead of your own main() method.
    }
}

Production Reality — Layered JARs and Docker Build Caching

Copying one monolithic fat JAR into a Docker image works, but it wastes the layer cache: any code change — even a single line — invalidates the entire image layer containing the JAR, forcing Docker to re-push every dependency on every deploy, even though your dependencies almost never change between builds. Since Spring Boot 2.3, the executable JAR supports being split into layers along exactly this boundary.

# Extract the JAR into its constituent layers
java -Djarmode=layertools -jar myapp.jar extract
# Produces (typically): dependencies/, spring-boot-loader/,
# snapshot-dependencies/, application/ — ordered from LEAST to MOST
# frequently changing

# Multi-stage Dockerfile using the extracted layers
FROM eclipse-temurin:21-jdk AS builder
WORKDIR /app
COPY target/myapp.jar app.jar
RUN java -Djarmode=layertools -jar app.jar extract

FROM eclipse-temurin:21-jre
WORKDIR /app
# Copied in order: layers that rarely change first, so Docker can reuse
# these cached layers across builds where only your own code changed
COPY --from=builder /app/dependencies/ ./
COPY --from=builder /app/spring-boot-loader/ ./
COPY --from=builder /app/snapshot-dependencies/ ./
COPY --from=builder /app/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]
# Check your Spring Boot version's own documentation for the exact
# launcher class name — it moved packages between major versions, and
# getting this wrong is a common source of a container that builds fine
# but fails immediately on "docker run"

EAR Files — Enterprise Archive, for Completeness

enterprise-app.ear
├── META-INF/application.xml   # declares which modules this EAR bundles
├── web-module.war
├── ejb-module.jar
└── lib/shared-utils.jar

An EAR bundles multiple WARs and JARs — typically a web tier plus an EJB tier — into one deployable unit for a full Jakarta EE application server. It was common in the Java EE era of monolithic enterprise deployments; today's equivalent goal (multiple coordinated modules deployed together) is far more often achieved with independent microservices, each its own JAR or container image, than with a single EAR bundling everything into one deployment unit.

Common Issues

"no main manifest attribute"

$ java -jar myapp.jar
no main manifest attribute, in myapp.jar

// Cause: the manifest has no Main-Class entry. Fix in pom.xml:
<manifest>
    <mainClass>com.shop.Main</mainClass>
</manifest>

ClassNotFoundException in what should be a fat JAR

# Verify what actually got bundled:
jar -tf myapp.jar | grep gson
# Nothing printed → dependencies were never included. Check that the
# repackage/shade execution actually ran during the build (mvn package,
# not mvn compile), and that the plugin is bound to the "package" phase.

javax vs jakarta package mismatch

java.lang.NoClassDefFoundError: javax/servlet/Servlet
// A javax.servlet-based WAR deployed to Tomcat 10+. Full explanation of
// this migration is on Servlet Containers and Tomcat Overview — the fix
// here is updating every affected import and dependency to jakarta.*.

Best Practices and Common Pitfalls

Interview Questions