Stephen C
Stephen C

Reputation: 719376

What does "Could not find or load main class" mean?

A common problem that new Java developers experience is that their programs fail to run with the error message: Could not find or load main class ...

What does this mean, what causes it, and how should you fix it?

Upvotes: 1938

Views: 4699588

Answers (30)

InfDreSta
InfDreSta

Reputation: 21

It is also worth noticing that a simple syntax mistake like added an extra space before argument like:

java -Xmx1G  -Xmn128M someClass

instead of

java -Xmx1G -Xmn128M someClass

Would also throw message "Could not find or load main class..." without any addition information. I faced this when playing minecraft and copy paste some random jvm arguments from the internet without pay attention, which I was thought some arguments itself causing trouble. In the end I have to peek through the long madness arguments chain and try every single combination, just to relize an single extra space that causing trouble.

Upvotes: -2

Data engineer
Data engineer

Reputation: 11

In Eclipse, under Run Configuration, you can show the command line Eclipse uses to run your program on the Dependencies tab.

Upvotes: 0

Stephen C
Stephen C

Reputation: 719376

The java <class-name> command syntax

First of all, you need to understand the correct way to launch a program using the java (or javaw) command.

The normal syntax1 is this:

    java [ <options> ] <class-name> [<arg> ...]

where <option> is a command line option (starting with a "-" character), <class-name> is a fully qualified Java class name, and <arg> is an arbitrary command line argument that gets passed to your application.


1 - There are some other syntaxes which are described near the end of this answer.

The fully qualified name (FQN) for the class is conventionally written as you would in Java source code; e.g.

    packagename.packagename2.packagename3.ClassName

However some versions of the java command allow you to use slashes instead of periods; e.g.

    packagename/packagename2/packagename3/ClassName

which (confusingly) looks like a file pathname, but isn't one. Note that the term fully qualified name is standard Java terminology ... not something I just made up to confuse you :-)

Here is an example of what a java command should look like:

    java -Xmx100m com.acme.example.ListUsers fred joe bert

The above is going to cause the java command to do the following:

  1. Search for the compiled version of the com.acme.example.ListUsers class.
  2. Load the class.
  3. Check that the class has a main method with signature, return type and modifiers given by public static void main(String[]). (Note, the method argument's name is NOT part of the signature.)
  4. Call that method passing it the command line arguments ("fred", "joe", "bert") as a String[].

Reasons why Java cannot find the class

When you get the message "Could not find or load main class ...", that means that the first step has failed. The java command was not able to find the class. And indeed, the "..." in the message will be the fully qualified class name that java is looking for.

So why might it be unable to find the class?

Reason #1 - you made a mistake with the classname argument

The first likely cause is that you may have provided the wrong class name. (Or ... the right class name, but in the wrong form.) Considering the example above, here are a variety of wrong ways to specify the class name:

  • Example #1 - a simple class name:

    java ListUser
    

    When the class is declared in a package such as com.acme.example, then you must use the full classname including the package name in the java command; e.g.

    java com.acme.example.ListUser
    
  • Example #2 - a filename or pathname rather than a class name:

    java ListUser.class
    java com/acme/example/ListUser.class
    
  • Example #3 - a class name with the casing incorrect:

    java com.acme.example.listuser
    
  • Example #4 - a typo

    java com.acme.example.mistuser
    
  • Example #5 - a source filename (except for Java 11 or later; see below)

    java ListUser.java
    
  • Example #6 - you forgot the class name entirely

    java lots of arguments
    
  • Example #7 - you forgot the -jar option when attempting to run an executable JAR file, and the java command has misconstrued the JAR file name as a class name

    java myProgram.jar
    

Reason #2 - the application's classpath is incorrectly specified

The second likely cause is that the class name is correct, but that the java command cannot find the class. To understand this, you need to understand the concept of the "classpath". This is explained well by the Oracle documentation:

So ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:

  1. Read the three documents linked above. (Yes ... READ them! It is important that a Java programmer understands at least the basics of how the Java classpath mechanisms works.)
  2. Look at command line and / or the CLASSPATH environment variable that is in effect when you run the java command. Check that the directory names and JAR file names are correct.
  3. If there are relative pathnames in the classpath, check that they resolve correctly ... from the current directory that is in effect when you run the java command.
  4. Check that the class (mentioned in the error message) can be located on the effective classpath.
  5. Note that the classpath syntax is different for Windows versus Linux and Mac OS. (The classpath separator is ; on Windows and : on the others. If you use the wrong separator for your platform, you won't get an explicit error message. Instead, you will get a nonexistent file or directory on the path that will be silently ignored.)

Reason #2a - the wrong directory is on the classpath

When you put a directory on the classpath, it notionally corresponds to the root of the qualified name space. Classes are located in the directory structure beneath that root, by mapping the fully qualified name to a pathname. So for example, if "/usr/local/acme/classes" is on the class path, then when the JVM looks for a class called com.acme.example.Foon, it will look for a ".class" file with this pathname:

  /usr/local/acme/classes/com/acme/example/Foon.class

If you had put "/usr/local/acme/classes/com/acme/example" on the classpath, then the JVM wouldn't be able to find the class.

Reason #2b - the subdirectory path doesn't match the FQN

If your classes FQN is com.acme.example.Foon, then the JVM is going to look for "Foon.class" in the directory "com/acme/example":

  • If your directory structure doesn't match the package naming as per the pattern above, the JVM won't find your class.

  • If you attempt rename a class by moving it, that will fail as well ... but the exception stacktrace will be different. It is liable to say something like this:

    Caused by: java.lang.NoClassDefFoundError: <path> (wrong name: <name>)
    

    because the FQN in the class file doesn't match what the class loader is expecting to find.

To give a concrete example, supposing that:

  • you want to run com.acme.example.Foon class,
  • the full file path is /usr/local/acme/classes/com/acme/example/Foon.class,
  • your current working directory is /usr/local/acme/classes/com/acme/example/,

then:

# wrong, FQN is needed
java Foon

# wrong, there is no `com/acme/example` folder in the current working directory
java com.acme.example.Foon

# wrong, similar to above
java -classpath . com.acme.example.Foon

# fine; relative classpath set
java -classpath ../../.. com.acme.example.Foon

# fine; absolute classpath set
java -classpath /usr/local/acme/classes com.acme.example.Foon

Notes:

  • The -classpath option can be shortened to -cp in most Java releases. Check the respective manual entries for java, javac and so on.
  • Think carefully when choosing between absolute and relative pathnames in classpaths. Remember that a relative pathname may "break" if the current directory changes.

Reason #2c - dependencies missing from the classpath

The classpath needs to include all of the other (non-system) classes that your application depends on. (The system classes are located automatically, and you rarely need to concern yourself with this.) For the main class to load correctly, the JVM needs to find:

(Note: the JLS and JVM specifications allow some scope for a JVM to load classes "lazily", and this can affect when a classloader exception is thrown.)

Reason #3 - the class has been declared in the wrong package

It occasionally happens that someone puts a source code file into the the wrong folder in their source code tree, or they leave out the package declaration. If you do this in an IDE, the IDE's compiler will tell you about this immediately. Similarly if you use a decent Java build tool, the tool will run javac in a way that will detect the problem. However, if you build your Java code by hand, you can do it in such a way that the compiler doesn't notice the problem, and the resulting ".class" file is not in the place that you expect it to be.

Still can't find the problem?

There lots of things to check, and it is easy to miss something. Try adding the -Xdiag option to the java command line (as the first thing after java). It will output various things about class loading, and this may offer you clues as to what the real problem is.

Also, consider possible problems caused by copying and pasting invisible or non-ASCII characters from websites, documents and so on. And consider "homoglyphs", where two letters or symbols look the same ... but aren't.

You may run into this problem if you have invalid or incorrect signatures in META-INF/*.SF. You can try opening up the .jar in your favorite ZIP editor, and removing files from META-INF until all you have is your MANIFEST.MF. However this is NOT RECOMMENDED in general. (The invalid signature may be the result of someone having injected malware into the original signed JAR file. If you erase the invalid signature, you are in infecting your application with the malware!) The recommended approach is to get hold of JAR files with valid signatures, or rebuild them from the (authentic) original source code.

Finally, you can apparently run into this problem if there is a syntax error in the MANIFEST.MF file (see https://stackoverflow.com/a/67145190/139985).


Alternative syntaxes for java

There are three alternative syntaxes for the launching Java programs using the java command.

  1. The syntax used for launching an "executable" JAR file is as follows:

    java [ <options> ] -jar <jar-file-name> [<arg> ...]
    

    e.g.

    java -Xmx100m -jar /usr/local/acme-example/listuser.jar fred
    

    The name of the entry-point class (i.e. com.acme.example.ListUser) and the classpath are specified in the MANIFEST of the JAR file. Anything you specify as a classpath on the command line is ignored with this syntax: only the Class-Path entry in the Manifest is used (and, transitively, those in any JAR files referenced by this entry). Note also that URLs in this Class-Path are relative to the location of the JAR it is contained in.

  2. The syntax for launching an application from a module (Java 9 and later) is as follows:

    java [ <options> ] --module <module>[/<mainclass>] [<arg> ...]
    

    The name of the entrypoint class is either defined by the <module> itself, or is given by the optional <mainclass>.

  3. From Java 11 onwards, you can use the java command to compile and run a single source code file using the following syntax:

    java [ <options> ] <sourcefile> [<arg> ...]
    

    where <sourcefile> is (typically) a file with the suffix ".java".

For more details, please refer to the official documentation for the java command for the Java release that you are using.


IDEs

A typical Java IDE has support for running Java applications in the IDE JVM itself or in a child JVM. These are generally immune from this particular exception, because the IDE uses its own mechanisms to construct the runtime classpath, identify the main class and create the java command line.

However it is still possible for this exception to occur, if you do things behind the back of the IDE. For example, if you have previously set up an Application Launcher for your Java app in Eclipse, and you then moved the JAR file containing the "main" class to a different place in the file system without telling Eclipse, Eclipse would unwittingly launch the JVM with an incorrect classpath.

In short, if you get this problem in an IDE, check for things like stale IDE state, broken project references or broken launcher configurations.

It is also possible for an IDE to simply get confused. IDE's are hugely complicated pieces of software comprising many interacting parts. Many of these parts adopt various caching strategies in order to make the IDE as a whole responsive. These can sometimes go wrong, and one possible symptom is problems when launching applications. If you suspect this could be happening, it is worth trying other things like restarting your IDE, rebuilding the project and so on.


Other References

Upvotes: 1652

Gayathri
Gayathri

Reputation: 165

For Java 17, I had to ensure one of the classes in a module atleast had a main method. Simply adding the main method fixed it for me

Upvotes: 0

Feng Zhang
Feng Zhang

Reputation: 1960

In my case, my class was referring a file which was opened outside Eclipse. So it could not regenerate class on recompiling. Need to make sure all issues in "Problems" tab are cleared out.

Upvotes: 0

Uldis Barbans
Uldis Barbans

Reputation: 59

Among all the answers so far, I lacked someone to call out this gross pitfall with regard to correct specification of application's classpath:

If your application and your dependencies are packaged as jars on the filesystem, and you try to run it using the java [options] <mainclass> variant, then supplying directory name(s) in CLASSPATH is not enough! You have to add the /* wildcard!

Documentation is kind of elusive on this:

If the class path option isn't used and [CLASSPATH] isn't set, then the user class path consists of the current directory (.).

...

This sentence would make you presume that running java com.acme.example.Gerbera with all the needed jars in your current directory would surely work by default. Alas, it doesn't. You need to read a bit further in the documentation. What you need to do is CLASSPATH=./* java com.acme.example.Gerbera, or alternatively enumerate all the .jar filenames literally, with the appropriate separator.

Upvotes: 2

Abdur Rehman
Abdur Rehman

Reputation: 555

For a new version of Java which is Java18 up to until 2022. You have to only write the package keyword and the folder name in which you have the java extension file and semicolon, like below:

package JavaProgramming;

because I have the hello.java file in the JavaProgramming file. Note: Never give the space while writing folder names for java. Like Java Programming you have to keep it like; JavaProgramming, etc;

The whole code structure of a simple hello world is given below:

package JavaProgramming;

public class hello {
  public static void main(String[] args) {
     System.out.println("Hello java after long time");
      }
    }

Upvotes: -1

Tohid Makari
Tohid Makari

Reputation: 2484

In Intellij IDE select run/debug>>edit configuration and then select proper JDK for build and run menu.

Upvotes: 1

M-Razavi
M-Razavi

Reputation: 3467

With keyword 'package'

If you have a package keyword in your source code (the main class is defined in a package), you should run it over the hierarchical directory, using the full name of the class (packageName.MainClassName).

Assume there is a source code file (Main.java):

package com.test;

public class Main {

    public static void main(String[] args) {
        System.out.println("salam 2nya\n");
    }
}

For running this code, you should place Main.Class in the package like directory:

C:\Users\workspace\testapp\com\test\Main.Java

Then change the current directory of the terminal to the root directory of the project:

cd C:\Users\workspace\testapp

And finally, run the code:

java com.test.Main

Without keyword 'package'

If you don't have any package on your source code name maybe you are wrong with the wrong command. Assume that your Java file name is Main.java, after compile:

javac Main.java

your compiled code will be Main.class

You will get that error if you call it using:

java Main.class

Instead, use this:

java Main

Upvotes: 119

leonidaa
leonidaa

Reputation: 402

Reason #2 - the application's classpath is incorrectly specified. Read the three documents linked previously. (Yes ... read them! It is important that a Java programmer understands at least the basics of how the Java classpath mechanisms works.) I want to add this documentation to this very good post from above.

JDK Tools and Utilities General General Information (file structure, classpath, how classes are found, changes) Enhancements (enhancements in JDK 7) Standard JDK Tools and Utilities

https://docs.oracle.com/javase/7/docs/technotes/tools/index.html

https://docs.oracle.com/javase/7/docs/technotes/tools/findingclasses.html

https://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html

How the Java Launcher Finds Classes Understanding the class path and package names

https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/javac.html

ClassLoader in Java The Java ClassLoader is a part of the Java Runtime Environment that dynamically loads Java classes into the Java Virtual Machine. The Java run time system does not need to know about files and file systems because of classloaders.

Java classes aren’t loaded into memory all at once, but when required by an application. At this point, the Java ClassLoader is called by the JRE and these ClassLoaders load classes into memory dynamically.

https://en.wikipedia.org/wiki/Java_Classloader

https://www.geeksforgeeks.org/classloader-in-java/

https://en.wikipedia.org/wiki/Java_virtual_machine

Enter image description here

Enter image description here

Enter image description here

Upvotes: -1

leonidaa
leonidaa

Reputation: 402

  • In IntelliJ IDEA, check your global libraries* and local libraries
  • Check in the libraries version file pom.xml, Maybe it is an old library
  • They are so many possibilities mentioned in the previous answers that need to be tried too

Upvotes: 0

tharinduwijewardane
tharinduwijewardane

Reputation: 2863

If your classes are in packages then you have to cd to the root directory of your project and run using the fully qualified name of the class (packageName.MainClassName).

Example:

My classes are in here:

D:\project\com\cse\

The fully qualified name of my main class is:

com.cse.Main

So I cd back to the root project directory:

D:\project

Then issue the java command:

java com.cse.Main

This answer is for rescuing newbie Java programmers from the frustration caused by a common mistake. I recommend you read the accepted answer for more in depth knowledge about the Java classpath.

Upvotes: 183

Shardayyy
Shardayyy

Reputation: 107

This is how I solved my issue.

I noticed if you are including jar files with your compilation, adding the current directory (./) to the classpath helps.

javac -cp "abc.jar;efg.jar" MyClass.java
java -cp "abc.jar;efg.jar" MyClass

vs.

javac -cp "**./**;abc.jar;efg.jar" MyClass.java<br>
java -cp "**./**;abc.jar;efg.jar" MyClass

Upvotes: -2

ritu mansata
ritu mansata

Reputation: 75

If your package name is javatpoint and the package name is com.javatpoint and the class name is AnotherOne, then compile your class like this type:

cd C:\Users\JAY GURUDEV\eclipse-workspace\javatpoint\src\com\javatpoint
javac AnotherOne.java

And run this class using

cd C:\Users\JAY GURUDEV\eclipse-workspace\javatpoint\src
java com.javatpoint.AnotherOne

(Here the package name should be excluded.)

Upvotes: -2

developer747
developer747

Reputation: 15958

Enter image description here

Class file location: C:\test\com\company

File Name: Main.class

Fully qualified class name: com.company.Main

Command line command:

java  -classpath "C:\test" com.company.Main

Note here that class path does not include \com\company.

Upvotes: 9

Juliano Soder
Juliano Soder

Reputation: 9

The simplest way you can fix it is by redownloading the Maven Apache here: https://maven.apache.org/download.cgi

Than you set your path again:

Enter image description here

System variable

Put the path there where you set your Apache Maven folder like: C:\Program Files\apache-maven-3.8.4\bin

Enter image description here

Restart the terminal or IDE, and it should work.

It always works for me.

Upvotes: -1

LOrD_ARaGOrN
LOrD_ARaGOrN

Reputation: 4516

I came one level up. So, now the HelloWorld.class file is in hello\HelloWorld.class and I ran the below command. Where cp is classpath and . means check in current directory only.

java -cp . hello.HelloWorld

Output

Hello world!

Upvotes: 2

Rahul Raghuvanshi
Rahul Raghuvanshi

Reputation: 56

For a database connection I was getting this one. I just added the following in the class path:

export CLASSPATH=<path>/db2jcc4.jar:**./**

Here I appended ./ in last so that my class also get identified while loading.

Now just run:

java ConnectionExample <args>

It worked perfectly fine.

Upvotes: -2

khichar.anil
khichar.anil

Reputation: 4984

I also faced similar errors while testing a Java MongoDB JDBC connection. I think it's good to summarize my final solution in short so that in the future anybody can directly look into the two commands and are good to proceed further.

Assume you are in the directory where your Java file and external dependencies (JAR files) exist.

Compile:

javac -cp mongo-java-driver-3.4.1.jar JavaMongoDBConnection.java
  • -cp - classpath argument; pass all the dependent JAR files one by one
  • *.java - This is the Java class file which has main method. sdsd

Run:

java -cp mongo-java-driver-3.4.1.jar: JavaMongoDBConnection
  • Please do observe the colon (Unix) / comma (Windows) after all the dependency JAR files end
  • At the end, observe the main class name without any extension (no .class or .java)

Upvotes: 5

Marco V
Marco V

Reputation: 2653

You really need to do this from the src folder. There you type the following command line:

[name of the package].[Class Name] [arguments]

Let's say your class is called CommandLine.class, and the code looks like this:

package com.tutorialspoint.java;

    /**
     * Created by mda21185 on 15-6-2016.
     */

    public class CommandLine {
        public static void main(String args[]){
            for(int i=0; i<args.length; i++){
                System.out.println("args[" + i + "]: " + args[i]);
            }
        }
    }

Then you should cd to the src folder and the command you need to run would look like this:

java com.tutorialspoint.java.CommandLine this is a command line 200 -100

And the output on the command line would be:

args[0]: this
args[1]: is
args[2]: a
args[3]: command
args[4]: line
args[5]: 200
args[6]: -100

Upvotes: 4

syntagma
syntagma

Reputation: 24344

What fixed the problem in my case was:

Right click on the project/class you want to run, and then Run AsRun Configurations. Then you should either fix your existing configuration or add a new one in the following way:

Open the Classpath tab, click on the Advanced... button, and then add bin folder of your project.

Upvotes: 5

GuiRitter
GuiRitter

Reputation: 757

This is a specific case:

Windows (tested with Windows 7) doesn't accept special characters (like á) in class and package names. Linux does, though.

I found this out when I built a .jar in NetBeans and tried to run it in command line. It ran in NetBeans, but not on the command line.

Upvotes: 5

Jaanus
Jaanus

Reputation: 16551

I got this error after doing mvn eclipse:eclipse. This messed up my .classpath file a little bit.

I had to change the lines in .classpath from

<classpathentry kind="src" path="src/main/java" including="**/*.java"/>
<classpathentry kind="src" path="src/main/resources" excluding="**/*.java"/>

to

<classpathentry kind="src" path="src/main/java" output="target/classes" />
<classpathentry kind="src" path="src/main/resources" excluding="**"  output="target/classes" />

Upvotes: 2

Anandaraja Ravi
Anandaraja Ravi

Reputation: 79

In Java, when you sometimes run the JVM from the command line using the Java interpreter executable and are trying to start a program from a class file with public static void main (PSVM), you might run into the below error even though the classpath parameter to the JVM is accurate and the class file is present on the classpath:

Error: main class not found or loaded

This happens if the class file with PSVM could not be loaded. One possible reason for that is that the class may be implementing an interface or extending another class that is not on the classpath. Normally if a class is not on the classpath, the error thrown indicates as such. But, if the class in use is extended or implemented, Java is unable to load the class itself.

Reference: https://www.computingnotes.net/java/error-main-class-not-found-or-loaded/

Upvotes: 4

Devs love ZenUML
Devs love ZenUML

Reputation: 11892

According to the error message ("Could not find or load main class"), there are two categories of problems:

  1. The Main class could not be found
  2. The Main class could not be loaded (this case is not fully discussed in the accepted answer)

The Main class could not be found when there is a typo or wrong syntax in the fully qualified class name or it does not exist in the provided classpath.

The Main class could not be loaded when the class cannot be initiated. Typically the main class extends another class and that class does not exist in the provided classpath.

For example:

public class YourMain extends org.apache.camel.spring.Main

If camel-spring is not included, this error will be reported.

Upvotes: 29

mathewbruens
mathewbruens

Reputation: 365

I thought that I was somehow setting my classpath incorrectly, but the problem was that I typed:

java -cp C:/java/MyClasses C:/java/MyClasses/utilities/myapp/Cool  

instead of:

java -cp C:/java/MyClasses utilities/myapp/Cool   

I thought the meaning of fully qualified meant to include the full path name instead of the full package name.

Upvotes: 7

Celebes
Celebes

Reputation: 1431

Specifying the classpath on the command line helped me. For example:

  1. Create a new folder, C:\temp

  2. Create file Temp.java in C:\temp, with the following class in it:

     public class Temp {
         public static void main(String args[]) {
             System.out.println(args[0]);
         }
     }
    
  3. Open a command line in folder C:\temp, and write the following command to compile the Temp class:

     javac Temp.java
    
  4. Run the compiled Java class, adding the -classpath option to let JRE know where to find the class:

     java -classpath C:\temp Temp Hello!
    

Upvotes: 43

KawaiKx
KawaiKx

Reputation: 9940

In my case, the error appeared because I had supplied the source file name instead of the class name.

We need to supply the class name containing the main method to the interpreter.

Upvotes: 9

TheWaterWave222
TheWaterWave222

Reputation: 139

It basically means that there isn't a static main(String[] args) method. It should resolve it automatically. If it doesn't, something was screwed when the program was either made (it doesn't have a main method) or when the program was packaged (incorrect manifest information.)

This works

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

This doesn't work

public class Hello {
    public Hello() {
        System.out.println("Hello");
    }
}

Upvotes: -1

SANN3
SANN3

Reputation: 10099

Excluding the following files solved the problem.

META-INF/*.SF

META-INF/*.DSA

META-INF/*.RSA

Added the following code in build.gradle

jar {
    from {
        configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
    }
    {
        exclude "META-INF/*.SF"
        exclude "META-INF/*.DSA"
        exclude "META-INF/*.RSA"
    }
    manifest {
        attributes(
                'Main-Class': 'mainclass'
        )
    }
}

Upvotes: -3

Related Questions