How to Fix "No Main Manifest Attribute" in a JAR File (Java)

By the end of this page, you will understand what the Java manifest file does, why java -jar requires a Main-Class, and why some JAR files are not meant to be launched directly. You will also learn how to inspect a JAR, check its manifest, identify whether it is a library or launcher component, and choose the correct way to run the application.

In Java, a JAR file is a ZIP-based archive that can contain compiled classes, resources, and metadata. One important piece of metadata is the manifest file, usually located at:

META-INF/MANIFEST.MF

When you run:

java -jar app.jar

Java does not search every class looking for a main method. Instead, it opens the JAR's manifest and looks for a special entry:

Main-Class: com.example.MyApp

If that entry is missing, Java cannot know which class to start, so it prints:

no main manifest attribute

Why this matters

This error does not always mean the application is broken. It often means one of these things:

• the JAR is a library, not a standalone application
• the JAR is only one part of a larger application
• the application is normally started by a script, launcher, IDE, installer, or wrapper
• the JAR was packaged incorrectly
• you are trying to run the wrong JAR in a folder containing several JARs

In real Java projects, not every JAR is executable. Many JARs are meant to be placed on the classpath and used by another program.

Key point

java -jar somefile.jar only works when that JAR contains a manifest with a valid entry. If it does not, you need to either:

Think of a JAR file like a box of parts.

• Some boxes are complete products with an instruction label on the outside.
• Some boxes are just components meant to be used inside a larger machine.

The manifest is like the label that says:

"Start here: use this class first."

When you use java -jar, Java reads that label.

• If the label exists, Java knows where to begin.
• If the label is missing, Java sees a box full of parts but has no instructions for which part to start with.

So the problem is usually not "Java cannot run classes." The problem is: Java was not told which class is the starting point.

The two most common ways to run Java code are:

1. Run a JAR that has a manifest entry

java -jar app.jar

This requires a manifest like:

Main-Class: com.example.App

2. Run a class directly by naming it

java -cp app.jar com.example.App

This does not require a Main-Class in the manifest. But it only works if:

• you know the fully qualified class name
• that class has a valid public static void main(String[] args) method

Example of a valid Java entry point

public class App {
    public static void main(String[] args) {
        System.out.println("Application started");
    }
}

If this class were packaged into a JAR, the manifest would need:

Main-Class: App

Or, if it were in a package:

Consider this command:

java -jar app.jar

Here is what Java does step by step:

Example scenario

Assume app.jar contains many .class files and resources.

Step 1: Java opens the JAR

Java treats the JAR as an archive and reads its metadata.

Step 2: Java looks for the manifest

It checks for:

META-INF/MANIFEST.MF

Step 3: Java searches for Main-Class

It expects a line like:

Main-Class: com.example.App

Step 4: If found, Java loads that class

Java then loads com.example.App and looks for:

public static void main(String[] args)

Step 5: The program starts

If the class exists and the main method is valid, execution begins.

This concept appears often in real Java work.

Desktop applications

A desktop app may include several JARs:

• one launcher JAR
• multiple library JARs
• native dependencies
• shell or batch scripts to start everything correctly

If you run the wrong JAR directly, you may get the manifest error.

Framework-generated applications

Some build tools generate:

• executable JARs
• thin JARs
• library JARs
• test JARs

Only some of them are meant to be started with java -jar.

Server applications

A server app might be started with a script like:

./start.sh

That script may set:

• the classpath n- JVM options
• environment variables
• config locations
• the actual main class

Running a single JAR manually can fail even though the app itself is valid.

Libraries from package folders

If you downloaded a JAR from a lib/ directory, it is probably a dependency, not a runnable application.

Installer-created apps

Some installers place launchers in system-specific formats and the JAR is only an internal component. On another machine the application may appear to "run fine" because a wrapper script or executable is starting it properly.

In real projects, developers usually handle application startup in more structured ways.

Common patterns

Executable JAR packaging

Build tools such as Maven or Gradle are configured to write a Main-Class into the manifest for runnable applications.

Wrapper scripts

Projects often provide:

• .sh files on Linux/macOS
• .bat or .cmd files on Windows

These scripts avoid startup mistakes by setting the correct classpath and options.

Bootstrap classes

Many applications do not start in the obvious business class. Instead they use a small bootstrap class that:

• validates environment variables
• loads configuration
• sets up logging
• handles errors early
• then starts the real app

Explicit classpath startup

Instead of relying on java -jar, developers may use:

java -cp "app.jar:lib/*" com.example.Main

or on Windows:

java -cp "app.jar;lib/*" com.example.Main

Beginners often make the following mistakes with JAR files.

1. Assuming every JAR is executable

A JAR is just a package format. It may be:

• a library
• a plugin
• a test artifact
• an executable app

Wrong assumption

java -jar commons-lang3.jar

This will fail because that JAR is a library, not an application.

2. Looking for a class named Main

The entry point class can have any name.

Wrong assumption

• Main.class must exist
• the file name must include the word main

Neither is required.

3. Confusing -jar with -cp

These are different startup modes.

Using -jar

java -jar app.jar

• uses the manifest
• ignores your normal classpath expectations
• requires Main-Class

Using

Quick reference

Run an executable JAR

java -jar app.jar

Requires manifest entry:

Main-Class: com.example.App

Run by naming the class directly

java -cp app.jar com.example.App

Inspect JAR contents

jar tf app.jar

Extract only the manifest

jar xf app.jar META-INF/MANIFEST.MF

What the error means

no main manifest attribute

Meaning:

• the JAR has no Main-Class entry
• or it is not meant to be run with java -jar

Things to check

• Is this the correct JAR?
• Is there a META-INF/MANIFEST.MF file?
• Does it contain Main-Class:?
• Is there a startup script like or ?

Why does Java say "no main manifest attribute"?

Because java -jar looked inside the JAR manifest and did not find a Main-Class entry telling it which class to run.

Can a JAR work without a manifest?

Yes. A JAR can still be used as a library on the classpath. It just cannot be launched with java -jar unless the manifest includes the correct entry point.

Can I run the JAR if I know the main class?

Yes. You can use:

java -cp app.jar com.example.MainClass

You may also need additional dependency JARs on the classpath.

Why does the app run on another computer?

That system may be using a launcher script, wrapper executable, shortcut, or a different JAR file that sets the correct startup class and dependencies.

How can I find the main class inside a JAR?

First inspect META-INF/MANIFEST.MF. If there is no Main-Class, search the compiled classes for a method with this signature:

public static void main(String[] args)

Can I just add a Main-Class to the manifest myself?

• Java JAR files — Understanding what a JAR contains helps explain why some archives are executable and others are just libraries.
• Manifest file — The manifest stores metadata such as Main-Class, which controls how java -jar starts an app.
• Java main method — This is the program entry point Java looks for after resolving the startup class.
• Classpath — Many apps need multiple JARs, so knowing how the classpath works is essential when -jar is not enough.
• Maven and Gradle packaging — Build tools often generate executable or non-executable JARs depending on configuration.
• Java command-line options — Flags like -jar and -cp behave differently and are often confused.
• Executable vs library artifacts — Distinguishing runnable deliverables from reusable dependencies avoids many startup errors.