Introduction

The META-INF directory is a reserved folder at the root of Java archive files (JAR, WAR, EAR) that holds metadata and configuration files describing how the archive should behave at build time, runtime, and deployment. The JVM and application servers read from this directory automatically, so its contents control everything from which class to execute, to how services are discovered, to whether the archive has been tampered with.

If you have ever wondered why your executable JAR launches the right main class, or how Spring discovers your beans without explicit registration, the answer is almost always a file inside META-INF.

The MANIFEST.MF File

MANIFEST.MF is the most important file in META-INF. Every JAR file created by standard tooling includes one. It is a plain-text key-value file that the JVM reads before doing anything else with the archive.

A minimal manifest for an executable JAR looks like this:

Manifest-Version: 1.0
Main-Class: com.example.App
Class-Path: lib/commons-lang3.jar lib/guava.jar

Key attributes and what they control:

You can also define per-package attributes by adding named sections:

1Manifest-Version: 1.0
2
3Name: com/example/api/
4Sealed: true
5Specification-Version: 2.0

This seals the com.example.api package, preventing other JARs from contributing classes to it at runtime, which protects against classpath conflicts and split-package issues.

JAR Signing and Security Files

When a JAR is signed, three additional files appear in META-INF:

1META-INF/
2  MANIFEST.MF
3  MYKEY.SF        # signature file (hashes of manifest entries)
4  MYKEY.RSA       # PKCS7 signature block (certificate + encrypted digest)

The .SF file contains digests of each section of MANIFEST.MF. The .RSA (or .DSA or .EC) file contains the actual cryptographic signature and the signer's certificate chain. Together they let the JVM verify that no file in the JAR has been modified since signing.

You can verify a signed JAR from the command line:

jarsigner -verify -verbose myapp.jar

If any class file has been altered, the verification fails. This mechanism is the foundation for Java WebStart security, applet trust decisions, and enterprise deployment policies.

Service Provider Interface (SPI)

The META-INF/services/ directory is central to Java's ServiceLoader mechanism, which enables modular, pluggable architectures without compile-time coupling.

Each file in services/ is named after a fully qualified interface or abstract class, and its contents list the concrete implementations:

META-INF/services/com.example.spi.PaymentProcessor

File contents:

com.example.stripe.StripeProcessor
com.example.paypal.PayPalProcessor

At runtime, the application discovers implementations dynamically:

1import java.util.ServiceLoader;
2
3public class PaymentRegistry {
4    public static void main(String[] args) {
5        ServiceLoader<PaymentProcessor> loader =
6            ServiceLoader.load(PaymentProcessor.class);
7
8        for (PaymentProcessor processor : loader) {
9            System.out.println("Found: " + processor.getClass().getName());
10        }
11    }
12}

This pattern is used extensively in the JDK itself (JDBC drivers, XML parsers, cryptographic providers) and in frameworks like SLF4J for logging backend discovery.

Framework-Specific Files in META-INF

Beyond standard JVM files, many frameworks place their own configuration in META-INF:

A typical JPA persistence.xml inside META-INF:

1<persistence xmlns="https://jakarta.ee/xml/ns/persistence" version="3.0">
2  <persistence-unit name="default">
3    <class>com.example.model.User</class>
4    <class>com.example.model.Order</class>
5    <properties>
6      <property name="jakarta.persistence.jdbc.url"
7                value="jdbc:postgresql://localhost:5432/mydb"/>
8    </properties>
9  </persistence-unit>
10</persistence>

META-INF in WAR and EAR Archives

In web archives (WAR), META-INF appears at the archive root, while web resources go under WEB-INF. In enterprise archives (EAR), META-INF holds application.xml, which declares the modules (WARs, EJB JARs) packaged inside.

Archive structure comparison:

1myapp.jar                    myapp.war                    myapp.ear
2  META-INF/                    META-INF/                    META-INF/
3    MANIFEST.MF                  MANIFEST.MF                  MANIFEST.MF
4    services/                  WEB-INF/                       application.xml
5  com/example/...                web.xml                    lib/
6                                 classes/                   myejb.jar
7                                 lib/                       myweb.war

The key point is that META-INF always lives at the archive root regardless of archive type, and different containers look for different files inside it.

Common Pitfalls

• Placing persistence.xml directly in the project root instead of inside META-INF. JPA will not find it and will fail silently or throw an opaque error about missing persistence units.
• Confusing META-INF in a JAR with WEB-INF in a WAR. These are different directories with different visibility rules. Files in META-INF are accessible via ClassLoader.getResource(), while WEB-INF contents are accessible through the ServletContext.
• Forgetting that META-INF/services/ files must use the fully qualified interface name as the filename, not the implementation name. Getting this reversed means ServiceLoader finds nothing.
• Editing MANIFEST.MF by hand and omitting the trailing newline. The manifest specification requires a newline at the end of the file, and some JVM implementations silently ignore the last entry if it is missing.
• Assuming all classes from META-INF/services/ are loaded eagerly. ServiceLoader is lazy by default; implementations are instantiated on iteration, which can mask startup errors until the service is actually used.

Summary

• META-INF is a reserved directory in Java archives that the JVM, application servers, and frameworks read automatically.
• MANIFEST.MF controls execution, versioning, classpath, and package sealing.
• Signing files (.SF, .RSA/.DSA) provide tamper-detection and identity verification.
• META-INF/services/ enables the ServiceLoader pattern for runtime plugin discovery.
• Frameworks like JPA, CDI, and Spring Boot place their own configuration files in META-INF for automatic discovery.
• The directory exists in JAR, WAR, and EAR archives, always at the archive root.