Related
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?
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:
Search for the compiled version of the com.acme.example.ListUsers class.
Load the class.
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.)
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
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:
The java command documentation
Setting the Classpath.
The Java Tutorial - PATH and CLASSPATH
So ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:
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.)
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.
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.
Check that the class (mentioned in the error message) can be located on the effective classpath.
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:
the class itself.
all classes and interfaces in the superclass hierarchy (e.g. see Java class is present in classpath but startup fails with Error: Could not find or load main class)
all classes and interfaces that are referred to by means of variable or variable declarations, or method call or field access expressions.
(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.
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.
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>.
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
From the Oracle Java Tutorials - Common Problems (and Their Solutions)
If your source code name is HelloWorld.java, your compiled code will be HelloWorld.class.
You will get that error if you call it using:
java HelloWorld.class
Instead, use this:
java HelloWorld
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.
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
When the same code works on one PC, but it shows the error in another, the best solution I have ever found is compiling like the following:
javac HelloWorld.java
java -cp . HelloWorld
Specifying the classpath on the command line helped me. For example:
Create a new folder, C:\temp
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]);
}
}
Open a command line in folder C:\temp, and write the following command to compile the Temp class:
javac Temp.java
Run the compiled Java class, adding the -classpath option to let JRE know where to find the class:
java -classpath C:\temp Temp Hello!
According to the error message ("Could not find or load main class"), there are two categories of problems:
The Main class could not be found
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.
Use this command:
java -cp . [PACKAGE.]CLASSNAME
Example: If your classname is Hello.class created from Hello.java then use the below command:
java -cp . Hello
If your file Hello.java is inside package com.demo then use the below command
java -cp . com.demo.Hello
With JDK 8 many times it happens that the class file is present in the same folder, but the java command expects classpath and for this reason we add -cp . to take the current folder as reference for classpath.
I had such an error in this case:
java -cp lib.jar com.mypackage.Main
It works with ; for Windows and : for Unix:
java -cp lib.jar; com.mypackage.Main
Try -Xdiag.
Steve C's answer covers the possible cases nicely, but sometimes to determine whether the class could not be found or loaded might not be that easy. Use java -Xdiag (since JDK 7). This prints out a nice stacktrace which provides a hint to what the message Could not find or load main class message means.
For instance, it can point you to other classes used by the main class that could not be found and prevented the main class to be loaded.
Sometimes what might be causing the issue has nothing to do with the main class, and I had to find this out the hard way. It was a referenced library that I moved, and it gave me the:
Could not find or load main class xxx Linux
I just deleted that reference, added it again, and it worked fine again.
I had same problem and finally found my mistake :)
I used this command for compiling and it worked correctly:
javac -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode.java
But this command did not work for me (I could not find or load the main class, qrcode):
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode
Finally I just added the ':' character at end of the classpath and the problem was solved:
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar:" qrcode
In this instance you have:
Could not find or load main class ?classpath
It's because you are using "-classpath", but the dash is not the same dash used by java on the command prompt. I had this issue copying and pasting from Notepad to cmd.
If you use Maven to build the JAR file, please make sure to specify the main class in the pom.xml file:
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>class name us.com.test.abc.MyMainClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
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.
This might help you if your case is specifically like mine: as a beginner I also ran into this problem when I tried to run a Java program.
I compiled it like this:
javac HelloWorld.java
And I tried to run also with the same extension:
java Helloworld.java
When I removed the .java and rewrote the command like java HelloWorld, the program ran perfectly. :)
All answers here are directed towards Windows users it seems. For Mac, the classpath separator is :, not ;. As an error setting the classpath using ; is not thrown then this can be a difficult to discover if coming from Windows to Mac.
Here is corresponding Mac command:
java -classpath ".:./lib/*" com.test.MyClass
Where in this example the package is com.test and a lib folder is also to be included on classpath.
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.
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.
On Windows put .; at the CLASSPATH value in the beginning.
The . (dot) means "look in the current directory". This is a permanent solution.
Also you can set it "one time" with set CLASSPATH=%CLASSPATH%;.. This will last as long as your cmd window is open.
When running the java with the -cp option as advertised in Windows PowerShell you may get an error that looks something like:
The term `ClassName` is not recognized as the name of a cmdlet, function, script ...
In order to for PowerShell to accept the command, the arguments of the -cp option must be contained in quotes as in:
java -cp 'someDependency.jar;.' ClassName
Forming the command this way should allow Java process the classpath arguments correctly.
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.
What fixed the problem in my case was:
Right click on the project/class you want to run, and then Run As → Run 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.
First set the path using this command;
set path="paste the set path address"
Then you need to load the program. Type "cd (folder name)" in the stored drive and compile it. For Example, if my program stored on the D drive, type "D:" press enter and type " cd (folder name)".
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/
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
All right, there are many answers already, but no one mentioned the case where file permissions can be the culprit.
When running, a user may not have access to the JAR file or one of the directories of the path. For example, consider:
Jar file in /dir1/dir2/dir3/myjar.jar
User1 who owns the JAR file may do:
# Running as User1
cd /dir1/dir2/dir3/
chmod +r myjar.jar
But it still doesn't work:
# Running as User2
java -cp "/dir1/dir2/dir3:/dir1/dir2/javalibs" MyProgram
Error: Could not find or load main class MyProgram
This is because the running user (User2) does not have access to dir1, dir2, or javalibs or dir3. It may drive someone nuts when User1 can see the files, and can access to them, but the error still happens for User2.
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)
I was unable to solve this problem with the solutions stated here (although the answer stated has, no doubt, cleared my concepts). I faced this problem two times and each time I have tried different solutions (in the Eclipse IDE).
Firstly, I have come across with multiple main methods in different classes of my project. So, I had deleted the main method from subsequent classes.
Secondly, I tried following solution:
Right click on my main project directory.
Head to source then clean up and stick with the default settings and on Finish. After some background tasks you will be directed to your main project directory.
After that I close my project, reopen it, and boom, I finally solved my problem.
Sometimes, in some online compilers that you might have tried you will get this error if you don't write public class [Classname] but just class [Classname].
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?
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:
Search for the compiled version of the com.acme.example.ListUsers class.
Load the class.
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.)
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
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:
The java command documentation
Setting the Classpath.
The Java Tutorial - PATH and CLASSPATH
So ... if you have specified the class name correctly, the next thing to check is that you have specified the classpath correctly:
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.)
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.
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.
Check that the class (mentioned in the error message) can be located on the effective classpath.
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:
the class itself.
all classes and interfaces in the superclass hierarchy (e.g. see Java class is present in classpath but startup fails with Error: Could not find or load main class)
all classes and interfaces that are referred to by means of variable or variable declarations, or method call or field access expressions.
(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.
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.
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>.
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
From the Oracle Java Tutorials - Common Problems (and Their Solutions)
If your source code name is HelloWorld.java, your compiled code will be HelloWorld.class.
You will get that error if you call it using:
java HelloWorld.class
Instead, use this:
java HelloWorld
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.
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
When the same code works on one PC, but it shows the error in another, the best solution I have ever found is compiling like the following:
javac HelloWorld.java
java -cp . HelloWorld
Specifying the classpath on the command line helped me. For example:
Create a new folder, C:\temp
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]);
}
}
Open a command line in folder C:\temp, and write the following command to compile the Temp class:
javac Temp.java
Run the compiled Java class, adding the -classpath option to let JRE know where to find the class:
java -classpath C:\temp Temp Hello!
According to the error message ("Could not find or load main class"), there are two categories of problems:
The Main class could not be found
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.
Use this command:
java -cp . [PACKAGE.]CLASSNAME
Example: If your classname is Hello.class created from Hello.java then use the below command:
java -cp . Hello
If your file Hello.java is inside package com.demo then use the below command
java -cp . com.demo.Hello
With JDK 8 many times it happens that the class file is present in the same folder, but the java command expects classpath and for this reason we add -cp . to take the current folder as reference for classpath.
I had such an error in this case:
java -cp lib.jar com.mypackage.Main
It works with ; for Windows and : for Unix:
java -cp lib.jar; com.mypackage.Main
Try -Xdiag.
Steve C's answer covers the possible cases nicely, but sometimes to determine whether the class could not be found or loaded might not be that easy. Use java -Xdiag (since JDK 7). This prints out a nice stacktrace which provides a hint to what the message Could not find or load main class message means.
For instance, it can point you to other classes used by the main class that could not be found and prevented the main class to be loaded.
Sometimes what might be causing the issue has nothing to do with the main class, and I had to find this out the hard way. It was a referenced library that I moved, and it gave me the:
Could not find or load main class xxx Linux
I just deleted that reference, added it again, and it worked fine again.
I had same problem and finally found my mistake :)
I used this command for compiling and it worked correctly:
javac -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode.java
But this command did not work for me (I could not find or load the main class, qrcode):
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar" qrcode
Finally I just added the ':' character at end of the classpath and the problem was solved:
java -cp "/home/omidmohebbi/AAAATest/jars/core-1.7.jar:/home/omidmohebbi/AAAATest/jars/javase-1.7.jar:/home/omidmohebbi/AAAATest/jars/qrgen-1.2.jar:" qrcode
In this instance you have:
Could not find or load main class ?classpath
It's because you are using "-classpath", but the dash is not the same dash used by java on the command prompt. I had this issue copying and pasting from Notepad to cmd.
If you use Maven to build the JAR file, please make sure to specify the main class in the pom.xml file:
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<mainClass>class name us.com.test.abc.MyMainClass</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
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.
This might help you if your case is specifically like mine: as a beginner I also ran into this problem when I tried to run a Java program.
I compiled it like this:
javac HelloWorld.java
And I tried to run also with the same extension:
java Helloworld.java
When I removed the .java and rewrote the command like java HelloWorld, the program ran perfectly. :)
All answers here are directed towards Windows users it seems. For Mac, the classpath separator is :, not ;. As an error setting the classpath using ; is not thrown then this can be a difficult to discover if coming from Windows to Mac.
Here is corresponding Mac command:
java -classpath ".:./lib/*" com.test.MyClass
Where in this example the package is com.test and a lib folder is also to be included on classpath.
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.
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.
On Windows put .; at the CLASSPATH value in the beginning.
The . (dot) means "look in the current directory". This is a permanent solution.
Also you can set it "one time" with set CLASSPATH=%CLASSPATH%;.. This will last as long as your cmd window is open.
When running the java with the -cp option as advertised in Windows PowerShell you may get an error that looks something like:
The term `ClassName` is not recognized as the name of a cmdlet, function, script ...
In order to for PowerShell to accept the command, the arguments of the -cp option must be contained in quotes as in:
java -cp 'someDependency.jar;.' ClassName
Forming the command this way should allow Java process the classpath arguments correctly.
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.
What fixed the problem in my case was:
Right click on the project/class you want to run, and then Run As → Run 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.
First set the path using this command;
set path="paste the set path address"
Then you need to load the program. Type "cd (folder name)" in the stored drive and compile it. For Example, if my program stored on the D drive, type "D:" press enter and type " cd (folder name)".
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/
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
All right, there are many answers already, but no one mentioned the case where file permissions can be the culprit.
When running, a user may not have access to the JAR file or one of the directories of the path. For example, consider:
Jar file in /dir1/dir2/dir3/myjar.jar
User1 who owns the JAR file may do:
# Running as User1
cd /dir1/dir2/dir3/
chmod +r myjar.jar
But it still doesn't work:
# Running as User2
java -cp "/dir1/dir2/dir3:/dir1/dir2/javalibs" MyProgram
Error: Could not find or load main class MyProgram
This is because the running user (User2) does not have access to dir1, dir2, or javalibs or dir3. It may drive someone nuts when User1 can see the files, and can access to them, but the error still happens for User2.
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)
I was unable to solve this problem with the solutions stated here (although the answer stated has, no doubt, cleared my concepts). I faced this problem two times and each time I have tried different solutions (in the Eclipse IDE).
Firstly, I have come across with multiple main methods in different classes of my project. So, I had deleted the main method from subsequent classes.
Secondly, I tried following solution:
Right click on my main project directory.
Head to source then clean up and stick with the default settings and on Finish. After some background tasks you will be directed to your main project directory.
After that I close my project, reopen it, and boom, I finally solved my problem.
Sometimes, in some online compilers that you might have tried you will get this error if you don't write public class [Classname] but just class [Classname].
I am trying to run a java program through the Terminal on Mac, yet getting:
Error: Could not find or load main class (MY CLASSNAME)
I compiled this application with Eclipse, and when I run this with Eclipse, it works fine.
Furthermore, I am in the right directory, as when I type "ls" in the Terminal, it lists all the files, includes the class file I am trying to run.
This is what I type:
java mainClass
I would very much appreciate help to solve this!
Thank you,
Dean
EDIT: Solution - instead of java mainClass, it must have package too: java startPackage.mainClass
Start by making sure you are at the directory above the top level package
If the class belongs to the package com.foo.bar, you want to be in the directory above com.
In your case, you want to be in the directory above startPack.
Then you need to use the fully qualified name to run the class...
java statPack.mainClass
For example...
Make sure you have the current directory inside your CLASSPATH.
java -cp . mainClass
To set this globally, you can use export CLASSPATH=$CLASSPATH:. inside .bash_profile.
Separately, if your class lives inside a package such as com.foo.bar, then you will need to go to the parent directory of com and run your application with the full path.
java com.foo.bar.mainClass
I too faced this on Mac machine and then what I had to do to make it work was:
Problem Statement:
I had one package xyz under the root of project i.e src/main/java and then inside xyz package I had one class Student.java
my current directory is /Users/username/projectname/src/main/java/xyz:
I can see Student.java exists here
and I compiled it using javac Student.java
Now I see class file has been created at this location. But when I try to run the class file using java Student
I get the error: Error: Could not find or load main class Student
Solution:
Now the solution is to go one step back in the directory and go to root path:/Users/username/projectname/src/main/java and run the command
java xyz.Student
and it will work.
Link to follow: https://javarevisited.blogspot.com/2015/04/error-could-not-find-or-load-main-class-helloworld-java.html
For people dumb like me, make sure you are typing java HelloWorld - and NOT java HelloWorld.class - to run the compiled file with the name HelloWorld.class. This is especially so if you are used to hitting the tab key to complete the file name, as the terminal will give you java HelloWorld.class if you hit the tab key for autocomplete after typing something like java He...
This answer is here because it took 3 sites, including this answer, and 25 mintues before I figured out what I was doing wrong.
Logic is easy, typing is hard.
Using the absolute path can also resolve this problem:
java -classpath /Users/xingliu/IdeaProjects/springproject/src/main/java/ startPackage.mainClass
I've downloaded two jars. I want to import some of their contained classes. How do I do this?
It's for my algorithms class. I've tried following the instructions on the following site to no avail.
http://algs4.cs.princeton.edu/code/
There's an installer for OSX (I'm running Mountain Lion) which allegedly adds the jars to your classpath. Unfortunately it also installs Dr. Java. I'd rather just use Sublime and Terminal. I assumed it would be easy enough just...
import java.stdlib;
in my Percolation.java file, but javac-ing that program yields a "package stdlib does not exist", as does
import stdlib;
I've added the location of stdlib.jar and algs4.jar to my Terminal CLASSPATH manually via:
export CLASSPATH=$CLASSPATH:/Users/Michael/path/to/jar/algs4.jar:/Users/Michael/path/to/jar/algs4.jar
export CLASSPATH=$CLASSPATH:/Users/Michael/path/to/jar/stdlib.jar:/Users/Michael/path/to/jar/stdlib.jar
I've also attempted
javac -cp $CLASSPATH:/Users/Michael/path/to/jar/algs4.jar:/Users/Michael/path/to/jar/stdlib.jar Percolation.java
But I still get a
javac Percolation.java
Percolation.java:1: cannot find symbol
symbol : class stdlib
location: package java
import java.stdlib;
^
Percolation.java:2: package java.algs4 does not exist
import java.algs4.WeightedQuickUnionUF;
^
What's going on here?
Also is there a way to permanently add those values to my CLASSPATH in OS X mountain lion. I have to perform that command with every new Terminal.
If you're using Terminal to compile and launch your program, then in the Terminal window, begin by setting the CLASSPATH:
$ export CLASSPATH=$CLASSPATH:/Users/Michael/path/to/jar1.jar:/Users/Michael/path/to/jar2.jar
Then you can type echo $CLASSPATH and see that the jars are referenced.
Now, in the same Terminal window, use javac to compile your class. Setting the CLASSPATH as above only applies to the current Terminal window and any processes launched from it.
Alternately you can pass the CLASSPATH to javac:
$ javac -cp $CLASSPATH:/Users/Michael/path/to/jar1.jar:/Users/Michael/path/to/jar2.jar MyClass.java
To persist this CLASSPATH for future Terminal sessions, add the export line above to the file .profile in your home directory.
It is outdated to answer this question, but maybe it will be useful for future participants of Princeton Algorithms course.
After adding CLASSPATH in environment java get classes from packages but still will generate errors on import command. You need to delete import algs4 and stdlib from source files and compilation will run smoothly.
This solution works on Ubuntu 12.04 with zsh.
You probably have the classpath stuff right. The class you're trying to import may not be called java.stdlib though. You need to import the fully qualified package name ... probably something like org.somecompany.ourlibrary.stdlib. Thus you would need
import org.somecompany.ourlibrary.stdlib
at the top of your Percolations.java file with the rest of the import statements.
Is your Percolation program contained in its own package? If so try putting it into the default package by commenting out any package statements from your files and recompiling it.
Also, nothing in algs4 is in the java package, it's all it's own separate thing.
If you're using Eclipse (as I do), select the current project, then you open the project properties from the menus. On the left you select "Java Build path", and then you select the tab libraries. Now you click the button "Add external Jars" and you point to your jar files, and you're done.
Good luck.
Launch javac with the -classpath <path_to_jar> option. Or edit the CLASSPATH environment variable so that it contains the JAR with the classes you wish to use.
I faced the same problem during work on this course, but for windows. I'll leave this comment here in case it will help somebody.
If you use DrJava you don't need any import statements in code. If you followed installation steps described in course, everything is configured for you.
But here can be a problem - it puts jar files in your current user directory, path to which can contain inappropriate symbols(russian letters in my case). You need to check it in Edit -> Preferences menu. You can see there algs4.jar and stdlib.jar paths. Make sure that this path are correct and point to real existing files.
I just moved all necessary files to another dir and changed paths in this menu. It solved this problem for me.
I wasted a lot of time with importing the class, tried the CL option of "javac -cp .;stdlib.jar mad.java" etc but used to get the same error you mentioned.
I then commented out the import altogether and made sure the DrJava's preferences had the 2 classpaths added + the %CLASSPATH% variable to have the right value. Is simply works now.
Good luck!
just name the package to default then it will work fine . also after that you dont need to import anyting just run some code provided in
Fundamentsls
chapter like
average
.
My solution was to add 2 new build systems to my Sublime text editor: one to compile and the other to execute. Use Tools->Build_system->New_build_system... from main menu with these two code snippets:
for compilation (I've named the file "algs-compile.sublime_build"):
{
"cmd": ["javac", "-cp", "/Users/admin/algs4/stdlib.jar:/Users/admin/algs4/algs4.jar:.", "$file"],
"file_regex": "^(...*?):([0-9]*):?([0-9]*)",
"selector": "source.java"
}
for running ("algs-run.sublime_build")
{
"cmd": ["java", "-cp", "/Users/admin/algs4/stdlib.jar:/Users/admin/algs4/algs4.jar:.", "$file_base_name"]
}
Don't forget to replace paths to jar-files here with the correct ones from your system.
I understand that this question is rather old but I hope this will help somebody.
If you are getting the "cannot be resolved to a type" error, and have tried adding the stdlib.jar or algs4.jar files, here is the solution:
The libraries in stdlib.jar and algs4.jar are in the "default" package. In Java, you can't access classes in the default package from a named package. If you need to use the libraries with a named package, you can use these package versions:
stdlib-package.jar and algs4-package.jar.
You can download these files here:
http://algs4.cs.princeton.edu/code/
Then you can automatically add the import:
import edu.princeton.cs.algs4.ClassName
Open your Sublime
Choose the Tools->Build System->New Build System
Add below code to the new file
This can tell the sublime to run the commands
{
"cmd": ["javac -cp /Users/yourusername/algs4/stdlib.jar:/Users/yourusername/algs4/algs4.jar:. \"$file\" && java -cp java -cp /Users/yourusername/algs4/stdlib.jar:/Users/yourusername/algs4/algs4.jar:. \"$file_base_name\""],
"shell":true,
"file_regex": "^(...*?):([0-9]*):?([0-9]*)",
"selector": "source.java"
}
Hope this can help those who are following the Algorithm Course from Princeton University
I had this same problem. Renfei Wang's solution worked for me (I don't have enough points yet to comment directly on his response).
In Sublime, navigate to Preferences: Browse Packages>JavaC.sublime_build.
Here's what mine looks like:
{
"cmd": ["javac", "-cp", "/Users/jason/Documents/lib/*:./","$file"],
"file_regex": "^(...*?):([0-9]*):?([0-9]*)",
"selector": "source.java"
}
/Users/jason/Documents/lib/*:/ lets Sublime know the location of the directory that holds my packages, so that now when I build, it loads those packages first.
Okay, I'm very new to linux and command line, and fairly new to java. I got an internship building a java program. I finally got it done on my machine (windows) and now I have to migrate it to a linux machine to test and then have it run as an executable. I have done much reading and researching on linux and understanding classpaths but it is still all very hard to fully comprehend. It's just not clicking for me yet. Can anyone explain the purpose of classpath in a simplified way using examples? One of the most confusing aspects to me is actually defining the physical path to the jar. Do I start all the way from usr or do I only need to begin from the jvm folder? If it matters, my java program is not located in the jvm folder. Can anyone shed some light for me?
EDIT: thank you guys very much for your help, I can't say that I'm fully in the clear but my understanding of my situation is a lot better.
Say you have multiple jar files a.jar,b.jar and c.jar. To add them to classpath while compiling you need to do
$javac -cp .:a.jar:b.jar:c.jar HelloWorld.java
To run do
$java -cp .:a.jar:b.jar:c.jar HelloWorld
You use the -classpath argument. You can use either a relative or absolute path. What that means is you can use a path relative to your current directory, OR you can use an absolute path that starts at the root /.
Example:
bash$ java -classpath path/to/jar/file MyMainClass
In this example the main function is located in MyMainClass and would be included somewhere in the jar file.
For compiling you need to use javac
Example:
bash$ javac -classpath path/to/jar/file MyMainClass.java
You can also specify the classpath via the environment variable, follow this example:
bash$ export CLASSPATH="path/to/jar/file:path/tojar/file2"
bash$ javac MyMainClass.java
For any normally complex java project you should look for the ant script named build.xml
The classpath is the place(s) where the java compiler (command: javac) and the JVM (command:java) look in order to find classes which your application reference.
What does it mean for an application to reference another class ? In simple words it means to use that class somewhere in its code:
Example:
public class MyClass{
private AnotherClass referenceToAnotherClass;
.....
}
When you try to compile this (javac) the compiler will need the AnotherClass class. The same when you try to run your application: the JVM will need the AnotherClass class.
In order to to find this class the javac and the JVM look in a particular (set of) place(s). Those places are specified by the classpath which on linux is a colon separated list of directories (directories where the javac/JVM should look in order to locate the AnotherClass when they need it).
So in order to compile your class and then to run it, you should make sure that the classpath contains the directory containing the AnotherClass class. Then you invoke it like this:
javac -classpath "dir1;dir2;path/to/AnotherClass;...;dirN" MyClass.java //to compile it
java -classpath "dir1;dir2;path/to/AnotherClass;...;dirN" MyClass //to run it
Usually classes come in the form of "bundles" called jar files/libraries. In this case you have to make sure that the jar containing the AnotherClass class is on your classpaht:
javac -classpath "dir1;dir2;path/to/jar/containing/AnotherClass;...;dirN" MyClass.java //to compile it
java -classpath ".;dir1;dir2;path/to/jar/containing/AnotherClass;...;dirN" MyClass //to run it
In the examples above you can see how to compile a class (MyClass.java) located in the working directory and then run the compiled class (Note the "." at the begining of the classpath which stands for current directory). This directory has to be added to the classpath too. Otherwise, the JVM won't be able to find it.
If you have your class in a jar file, as you specified in the question, then you have to make sure that jar is in the classpath too , together with the rest of the needed directories.
Example:
java -classpath ".;dir1;dir2;path/to/jar/containing/AnotherClass;path/to/MyClass/jar...;dirN" MyClass //to run it
or more general (assuming some package hierarchy):
java -classpath ".;dir1;dir2;path/to/jar/containing/AnotherClass;path/to/MyClass/jar...;dirN" package.subpackage.MyClass //to run it
In order to avoid setting the classpath everytime you want to run an application you can define an environment variable called CLASSPATH.
In linux, in command prompt:
export CLASSPATH="dir1;dir2;path/to/jar/containing/AnotherClass;...;dirN"
or edit the ~/.bashrc and add this line somewhere at the end;
However, the class path is subject to frequent changes so, you might want to have the classpath set to a core set of dirs, which you need frequently and then extends the classpath each time you need for that session only. Like this:
export CLASSPATH=$CLASSPATH:"new directories according to your current needs"
For linux users, you should know the following:
$CLASSPATH is specifically what Java uses to look through multiple directories to find all the different classes it needs for your script (unless you explicitly tell it otherwise with the -cp override). Using -cp (--classpath) requires that you keep track of all the directories manually and copy-paste that line every time you run the program (not preferable IMO).
The colon (":") character separates the different directories. There is only one $CLASSPATH and it has all the directories in it. So, when you run "export CLASSPATH=...." you want to include the current value "$CLASSPATH" in order to append to it. For example:
export CLASSPATH=.
export CLASSPATH=$CLASSPATH:/usr/share/java/mysql-connector-java-5.1.12.jar
In the first line above, you start CLASSPATH out with just a simple 'dot' which is the path to your current working directory. With that, whenever you run java it will look in the current working directory (the one you're in) for classes. In the second line above, $CLASSPATH grabs the value that you previously entered (.) and appends the path to a mysql dirver. Now, java will look for the driver AND for your classes.
echo $CLASSPATH
is super handy, and what it returns should read like a colon-separated list of all the directories you want java looking in for what it needs to run your script.
Tomcat does not use CLASSPATH. Read what to do about that here: https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
Step 1.
vi ~/.bashrc
Step 2. Append this line on the last:
export CLASSPATH=$CLASSPATH:/home/abc/lib/*; (Assuming the jars are stored in /home/abc/lib)
Step 3.
source ~/.bashrc
After these steps direct complile and run your programs(e.g. javac xyz.java)