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 Main-Class entry. If it does not, you need to either:

• run a different JAR
• run the program using its documented startup script
• specify the main class manually with -cp
• or fix the packaging if you control the build

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:

package com.example;

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

Then the manifest would need:

Main-Class: com.example.App

How to inspect the manifest

You can list the contents of the JAR:

jar tf app.jar

You can extract the manifest:

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

Then open:

META-INF/MANIFEST.MF

If you do not see Main-Class, then java -jar cannot launch that JAR directly.

Example manifest

Manifest-Version: 1.0
Main-Class: com.example.App

That is the metadata Java needs for java -jar.

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.

What happens in your error case

If the manifest looks like this:

Manifest-Version: 1.0
Created-By: SomeTool

then Java reaches Step 3 and finds no Main-Class entry.

At that point it stops and prints:

no main manifest attribute, in app.jar

Important detail

Java does not scan every class in the archive looking for a main() method when using -jar.

That is why extracting the JAR and looking through class names is usually not enough. A main class can be named anything, such as:

• Launcher
• Bootstrap
• Start
• App
• Client

It does not have to contain the word main in the filename or class name.

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

This is common when the application depends on multiple JAR files.

Validation and early failure

Startup code often checks required configuration first and exits with a clear error. That is one reason many projects prefer a launcher class or script rather than expecting users to run internal JARs manually.

What to do in a real codebase

If you are debugging a third-party app:

1. inspect the JAR manifest
2. look for startup scripts in the installation folder
3. check documentation or README files
4. identify whether the JAR is a library or an executable
5. if needed, search classes for a real main method instead of relying on names alone

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 -cp

java -cp app.jar com.example.App

• you provide the main class yourself
• useful when the manifest is missing

4. Editing the JAR without understanding dependencies

Even if you add a Main-Class, the application may still fail if:

• dependencies are missing
• the wrong class is chosen
• startup scripts were supposed to configure the environment

5. Searching by filename instead of method signature

A class may contain a valid entry point even if its name is not obvious.

The real thing to search for is:

public static void main(String[] args)

6. Running the wrong file from the installation directory

Some folders contain many JARs, for example:

• app.jar
• app-core.jar
• launcher.jar
• lib/*.jar

Only one of them may be intended for direct execution.

Broken example: assuming class names tell you everything

com/example/Engine.class
com/example/Bootstrap.class
com/example/UiClient.class

A beginner might ignore these because none is named Main, but Bootstrap could easily contain the entry point.

How to avoid these mistakes

• inspect META-INF/MANIFEST.MF
• check for launch scripts
• search for main(String[] args) if necessary
• verify whether the JAR is documented as executable

Executable JAR vs library JAR

-jar vs -cp

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 run.sh or app.bat?
• Is this actually a library JAR?

Important rule

java -jar does not search all classes for main().

If you know the main class

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

On Windows:

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

Common edge case

A program may work on another system because that system launches it using:

• a wrapper executable
• a shell script
• a batch file
• an IDE configuration
• an installer-created shortcut

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?

Only if you understand how the application is packaged. Adding it may not be enough if the app also depends on other JARs, startup parameters, or environment configuration.

Does the main class have to be named Main?

No. The class can have any valid name. What matters is that it contains a proper main method.

Is this always a packaging bug?

No. Often it simply means the file is not intended to be run directly as an executable JAR.

• 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.