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?
classjavamain
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?
It's boilerplate code that protects users from accidentally invoking the script when they didn't intend to. Here are some common problems when the guard is omitted from a script:
If you import the guardless script in another script (e.g. import my_script_without_a_name_eq_main_guard
), then the second script will trigger the first to run at import time and using the second script's command line arguments. This is almost always a mistake.
If you have a custom class in the guardless script and save it to a pickle file, then unpickling it in another script will trigger an import of the guardless script, with the same problems outlined in the previous bullet.
To better understand why and how this matters, we need to take a step back to understand how Python initializes scripts and how this interacts with its module import mechanism.
Whenever the Python interpreter reads a source file, it does two things:
it sets a few special variables like __name__
, and then
it executes all of the code found in the file.
Let's see how this works and how it relates to your question about the __name__
checks we always see in Python scripts.
Let's use a slightly different code sample to explore how imports and scripts work. Suppose the following is in a file called foo.py
.
# Suppose this is foo.py.
print("before import")
import math
print("before functionA")
def functionA():
print("Function A")
print("before functionB")
def functionB():
print("Function B {}".format(math.sqrt(100)))
print("before __name__ guard")
if __name__ == '__main__':
functionA()
functionB()
print("after __name__ guard")
When the Python interpreter reads a source file, it first defines a few special variables. In this case, we care about the __name__
variable.
When Your Module Is the Main Program
If you are running your module (the source file) as the main program, e.g.
python foo.py
the interpreter will assign the hard-coded string "__main__"
to the __name__
variable, i.e.
# It's as if the interpreter inserts this at the top
# of your module when run as the main program.
__name__ = "__main__"
When Your Module Is Imported By Another
On the other hand, suppose some other module is the main program and it imports your module. This means there's a statement like this in the main program, or in some other module the main program imports:
# Suppose this is in some other main program.
import foo
The interpreter will search for your foo.py
file (along with searching for a few other variants), and prior to executing that module, it will assign the name "foo"
from the import statement to the __name__
variable, i.e.
# It's as if the interpreter inserts this at the top
# of your module when it's imported from another module.
__name__ = "foo"
After the special variables are set up, the interpreter executes all the code in the module, one statement at a time. You may want to open another window on the side with the code sample so you can follow along with this explanation.
Always
It prints the string "before import"
(without quotes).
It loads the math
module and assigns it to a variable called math
. This is equivalent to replacing import math
with the following (note that __import__
is a low-level function in Python that takes a string and triggers the actual import):
# Find and load a module given its string name, "math",
# then assign it to a local variable called math.
math = __import__("math")
It prints the string "before functionA"
.
It executes the def
block, creating a function object, then assigning that function object to a variable called functionA
.
It prints the string "before functionB"
.
It executes the second def
block, creating another function object, then assigning it to a variable called functionB
.
It prints the string "before __name__ guard"
.
Only When Your Module Is the Main Program
__name__
was indeed set to "__main__"
and it calls the two functions, printing the strings "Function A"
and "Function B 10.0"
.Only When Your Module Is Imported by Another
__name__
will be "foo"
, not "__main__"
, and it'll skip the body of the if
statement.Always
"after __name__ guard"
in both situations.Summary
In summary, here's what'd be printed in the two cases:
# What gets printed if foo is the main program
before import
before functionA
before functionB
before __name__ guard
Function A
Function B 10.0
after __name__ guard
# What gets printed if foo is imported as a regular module
before import
before functionA
before functionB
before __name__ guard
after __name__ guard
You might naturally wonder why anybody would want this. Well, sometimes you want to write a .py
file that can be both used by other programs and/or modules as a module, and can also be run as the main program itself. Examples:
Your module is a library, but you want to have a script mode where it runs some unit tests or a demo.
Your module is only used as a main program, but it has some unit tests, and the testing framework works by importing .py
files like your script and running special test functions. You don't want it to try running the script just because it's importing the module.
Your module is mostly used as a main program, but it also provides a programmer-friendly API for advanced users.
Beyond those examples, it's elegant that running a script in Python is just setting up a few magic variables and importing the script. "Running" the script is a side effect of importing the script's module.
Question: Can I have multiple __name__
checking blocks? Answer: it's strange to do so, but the language won't stop you.
Suppose the following is in foo2.py
. What happens if you say python foo2.py
on the command-line? Why?
# Suppose this is foo2.py.
import os, sys; sys.path.insert(0, os.path.dirname(__file__)) # needed for some interpreters
def functionA():
print("a1")
from foo2 import functionB
print("a2")
functionB()
print("a3")
def functionB():
print("b")
print("t1")
if __name__ == "__main__":
print("m1")
functionA()
print("m2")
print("t2")
__name__
check in foo3.py
:# Suppose this is foo3.py.
import os, sys; sys.path.insert(0, os.path.dirname(__file__)) # needed for some interpreters
def functionA():
print("a1")
from foo3 import functionB
print("a2")
functionB()
print("a3")
def functionB():
print("b")
print("t1")
print("m1")
functionA()
print("m2")
print("t2")
# Suppose this is in foo4.py
__name__ = "__main__"
def bar():
print("bar")
print("before __name__ guard")
if __name__ == "__main__":
bar()
print("after __name__ guard")
Here's the problem when I get too carried away with anonymous inner classes:
2009/05/27 16:35 1,602 DemoApp2$1.class
2009/05/27 16:35 1,976 DemoApp2$10.class
2009/05/27 16:35 1,919 DemoApp2$11.class
2009/05/27 16:35 2,404 DemoApp2$12.class
2009/05/27 16:35 1,197 DemoApp2$13.class
/* snip */
2009/05/27 16:35 1,953 DemoApp2$30.class
2009/05/27 16:35 1,910 DemoApp2$31.class
2009/05/27 16:35 2,007 DemoApp2$32.class
2009/05/27 16:35 926 DemoApp2$33$1$1.class
2009/05/27 16:35 4,104 DemoApp2$33$1.class
2009/05/27 16:35 2,849 DemoApp2$33.class
2009/05/27 16:35 926 DemoApp2$34$1$1.class
2009/05/27 16:35 4,234 DemoApp2$34$1.class
2009/05/27 16:35 2,849 DemoApp2$34.class
/* snip */
2009/05/27 16:35 614 DemoApp2$40.class
2009/05/27 16:35 2,344 DemoApp2$5.class
2009/05/27 16:35 1,551 DemoApp2$6.class
2009/05/27 16:35 1,604 DemoApp2$7.class
2009/05/27 16:35 1,809 DemoApp2$8.class
2009/05/27 16:35 2,022 DemoApp2$9.class
These are all classes which were generated when I was making a simple application, and used copious amounts of anonymous inner classes -- each class will be compiled into a separate class
file.
The "double brace initialization", as already mentioned, is an anonymous inner class with an instance initialization block, which means that a new class is created for each "initialization", all for the purpose of usually making a single object.
Considering that the Java Virtual Machine will need to read all those classes when using them, that can lead to some time in the bytecode verfication process and such. Not to mention the increase in the needed disk space in order to store all those class
files.
It seems as if there is a bit of overhead when utilizing double-brace initialization, so it's probably not such a good idea to go too overboard with it. But as Eddie has noted in the comments, it's not possible to be absolutely sure of the impact.
Just for reference, double brace initialization is the following:
List<String> list = new ArrayList<String>() {{
add("Hello");
add("World!");
}};
It looks like a "hidden" feature of Java, but it is just a rewrite of:
List<String> list = new ArrayList<String>() {
// Instance initialization block
{
add("Hello");
add("World!");
}
};
So it's basically a instance initialization block that is part of an anonymous inner class.
Joshua Bloch's Collection Literals proposal for Project Coin was along the lines of:
List<Integer> intList = [1, 2, 3, 4];
Set<String> strSet = {"Apple", "Banana", "Cactus"};
Map<String, Integer> truthMap = { "answer" : 42 };
Sadly, it didn't make its way into neither Java 7 nor 8 and was shelved indefinitely.
Experiment
Here's the simple experiment I've tested -- make 1000 ArrayList
s with the elements "Hello"
and "World!"
added to them via the add
method, using the two methods:
Method 1: Double Brace Initialization
List<String> l = new ArrayList<String>() {{
add("Hello");
add("World!");
}};
Method 2: Instantiate an ArrayList
and add
List<String> l = new ArrayList<String>();
l.add("Hello");
l.add("World!");
I created a simple program to write out a Java source file to perform 1000 initializations using the two methods:
Test 1:
class Test1 {
public static void main(String[] s) {
long st = System.currentTimeMillis();
List<String> l0 = new ArrayList<String>() {{
add("Hello");
add("World!");
}};
List<String> l1 = new ArrayList<String>() {{
add("Hello");
add("World!");
}};
/* snip */
List<String> l999 = new ArrayList<String>() {{
add("Hello");
add("World!");
}};
System.out.println(System.currentTimeMillis() - st);
}
}
Test 2:
class Test2 {
public static void main(String[] s) {
long st = System.currentTimeMillis();
List<String> l0 = new ArrayList<String>();
l0.add("Hello");
l0.add("World!");
List<String> l1 = new ArrayList<String>();
l1.add("Hello");
l1.add("World!");
/* snip */
List<String> l999 = new ArrayList<String>();
l999.add("Hello");
l999.add("World!");
System.out.println(System.currentTimeMillis() - st);
}
}
Please note, that the elapsed time to initialize the 1000 ArrayList
s and the 1000 anonymous inner classes extending ArrayList
is checked using the System.currentTimeMillis
, so the timer does not have a very high resolution. On my Windows system, the resolution is around 15-16 milliseconds.
The results for 10 runs of the two tests were the following:
Test1 Times (ms) Test2 Times (ms)
---------------- ----------------
187 0
203 0
203 0
188 0
188 0
187 0
203 0
188 0
188 0
203 0
As can be seen, the double brace initialization has a noticeable execution time of around 190 ms.
Meanwhile, the ArrayList
initialization execution time came out to be 0 ms. Of course, the timer resolution should be taken into account, but it is likely to be under 15 ms.
So, there seems to be a noticeable difference in the execution time of the two methods. It does appear that there is indeed some overhead in the two initialization methods.
And yes, there were 1000 .class
files generated by compiling the Test1
double brace initialization test program.
Best Answer
The
java <class-name>
command syntaxFirst of all, you need to understand the correct way to launch a program using the
java
(orjavaw
) command.The normal syntax1 is this:
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.
However some versions of the
java
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
java
command should look like:The above is going to cause the
java
command to do the following:com.acme.example.ListUsers
class.main
method with signature, return type and modifiers given bypublic static void main(String[])
. (Note, the method argument's name is NOT part of the signature.)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 thatjava
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:
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 thejava
command; e.g.Example #2 - a filename or pathname rather than a class name:
Example #3 - a class name with the casing incorrect:
Example #4 - a typo
Example #5 - a source filename (except for Java 11 or later; see below)
Example #6 - you forgot the class name entirely
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:java
command documentationSo ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:
java
command. Check that the directory names and JAR file names are correct.java
command.;
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: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:
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:
com.acme.example.Foon
class,/usr/local/acme/classes/com/acme/example/Foon.class
,/usr/local/acme/classes/com/acme/example/
,then:
Notes:
-classpath
option can be shortened to-cp
in most Java releases. Check the respective manual entries forjava
,javac
and so on.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 runjavac
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 thejava
command line (as the first thing afterjava
). 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.
Finally, you can apparently run into this problem if you try to launch from a JAR file with incorrect signatures in
(META-INF/*.SF)
or if there is a syntax error in theMANIFEST.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
.The syntax used for launching an "executable" JAR file is as follows:
e.g.
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.The syntax for launching an application from a module (Java 9 and later) is as follows:
The name of the entrypoint class is either defined by the
<module>
itself, or is given by the optional<mainclass>
.From Java 11 onwards, you can use the
java
command to compile and run a single source code file using the following syntax: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