Error could not find or load main class lỗi năm 2024
The Java error “Could not find or load main class” is thrown when the JVM fails to find or load the main class while executing a program. This is often due to simple mistakes like typing the wrong class name or having the class file in the wrong place. It usually occurs when executing a Java program from the command line. Show Install the Rollbar Java SDK to identify and fix these errors What Causes "Error: Could not find or load main class"It typically arises from issues like an incorrect class name, a mismatch in the directory and package structure, or a misconfigured classpath. Here's a full list of things to check:
"Error: Could not find or load main class" ExampleHere’s an example of the Java "Could not find or load main class" error thrown when an incorrect class name is specified during execution: Say you have an example Java class
You then compile the above class using the command line:
The compiler generates an executable .class file for MyClass:
Now if the
The generated .class file has the exact same name as the Java class, which in this case is
How to Fix "Error: Could not find or load main class"Most of the time, the error occurs because of specifying an incorrect class name, class file extension, file path or classpath. Follow these tips to resolve it:
Track, Analyze and Manage Errors With RollbarManaging errors and exceptions in your code is challenging. It can make deploying production code an unnerving experience. Being able to track, analyze, and manage errors in real-time can help you to proceed with more confidence. Rollbar automates error monitoring and triaging, making fixing Java errors easier than ever. Sign Up Today! First of all, you need to understand the correct way to launch a program using the
9 (or
The normal syntax1 is this:
where
1 is a command line option (starting with a "-" character),
2 is a fully qualified Java class name, and
3 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.
However some versions of the
9 command allow you to use slashes instead of periods; e.g.
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
9 command should look like:
The above is going to cause the
9 command to do the following:
Reasons why Java cannot find the classWhen you get the message "Could not find or load main class ...", that means that the first step has failed. The
9 command was not able to find the class. And indeed, the "..." in the message will be the fully qualified class name that
9 is looking for. So why might it be unable to find the class? Reason1 - you made a mistake with the classname argumentThe 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:
Reason2 - the application's classpath is incorrectly specifiedThe second likely cause is that the class name is correct, but that the
9 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:
Reason2a - the wrong directory is on the classpathWhen 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
1, it will look for a ".class" file with this pathname:
1 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. Reason2b - the subdirectory path doesn't match the FQNIf your classes FQN is
1, then the JVM is going to look for "Foon.class" in the directory "com/acme/example":
To give a concrete example, supposing that:
then:
3 Notes:
Reason2c - dependencies missing from the classpathThe 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.) Reason3 - the class has been declared in the wrong packageIt occasionally happens that someone puts a source code file into the the wrong folder in their source code tree, or they leave out the
0 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
9 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
2 option to the
9 command line (as the first thing after
9). 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
5. You can try opening up the .jar in your favorite ZIP editor, and removing files from
6 until all you have is your
7. 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
7 file (see https://stackoverflow.com/a/67145190/139985). Alternative syntaxes for
9 There are three alternative syntaxes for the launching Java programs using the
0.
For more details, please refer to the official documentation for the
9 command for the Java release that you are using. IDEsA 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
9 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. |