Could not find or load main class ошибка

The java <class-name> command syntax

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

The normal syntax1 is this:

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

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


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

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

    packagename.packagename2.packagename3.ClassName

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

    packagename/packagename2/packagename3/ClassName

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

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

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

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

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

Reasons why Java cannot find the class

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

So why might it be unable to find the class?

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

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

  • Example #1 — a simple class name:

    java ListUser
    

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

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

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

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

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

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

    java lots of arguments
    

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:

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

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

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

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

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

Reason #2b — the subdirectory path doesn’t match the FQN

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

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

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

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

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

To give a concrete example, supposing that:

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

then:

# wrong, FQN is needed
java Foon

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

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

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

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

Notes:

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

Reason #2c — dependencies missing from the classpath

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

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

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

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

    e.g.

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

    The name of the entry-point class (i.e. com.acme.example.ListUser) and the classpath are specified in the MANIFEST of the JAR file.

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

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

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

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

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

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

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


IDEs

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

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

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

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


Other References

  • From the Oracle Java Tutorials — Common Problems (and Their Solutions)

The java <class-name> command syntax

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

The normal syntax1 is this:

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

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


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

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

    packagename.packagename2.packagename3.ClassName

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

    packagename/packagename2/packagename3/ClassName

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

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

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

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

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

Reasons why Java cannot find the class

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

So why might it be unable to find the class?

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

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

  • Example #1 — a simple class name:

    java ListUser
    

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

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

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

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

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

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

    java lots of arguments
    

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:

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

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

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

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

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

Reason #2b — the subdirectory path doesn’t match the FQN

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

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

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

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

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

To give a concrete example, supposing that:

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

then:

# wrong, FQN is needed
java Foon

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

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

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

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

Notes:

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

Reason #2c — dependencies missing from the classpath

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

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

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

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

    e.g.

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

    The name of the entry-point class (i.e. com.acme.example.ListUser) and the classpath are specified in the MANIFEST of the JAR file.

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

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

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

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

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

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

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


IDEs

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

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

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

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


Other References

  • From the Oracle Java Tutorials — Common Problems (and Their Solutions)

Ошибка «Could not find or load main class» в Java – одна из самых распространенных проблем, с которой сталкиваются начинающие разработчики. Эта ошибка возникает,

Ошибка «Could not find or load main class» в Java – одна из самых распространенных проблем, с которой сталкиваются начинающие разработчики. Эта ошибка возникает, когда Java Runtime Environment не может найти главный класс, который был указан для выполнения.

В качестве примера рассмотрим следующий код:

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

Если вы скомпилируете этот код, используя javac HelloWorld.java, и затем попытаетесь выполнить его с помощью java HelloWorld, но получите ошибку «Could not find or load main class HelloWorld», это означает, что среда выполнения Java не может найти класс HelloWorld.

Причины возникновения ошибки

Основные причины, по которым может возникнуть эта ошибка, включают:

  • Некорректное имя класса. Java чувствительна к регистру, поэтому helloworld и HelloWorld — это разные имена.
  • Класс находится в пакете, и его имя должно быть полным, включая имя пакета. Например, java com.example.HelloWorld.
  • Класс скомпилирован, но находится вне класспути.
  • Отсутствует метод main в классе.

Решение проблемы

Чтобы решить эту проблему, следует выполнить следующие шаги:

  1. Убедитесь, что имя класса указано правильно. Java чувствительна к регистру, поэтому HelloWorld и helloworld — это разные имена.
  2. Если класс находится в пакете, убедитесь, что вы указали полное имя класса, включая имя пакета. Например, java com.example.HelloWorld.
  3. Проверьте класспуть. Если класс скомпилирован, но находится вне класспути, вам нужно добавить его в класспуть или изменить класспуть таким образом, чтобы он включал каталог, в котором находится скомпилированный класс.
  4. Убедитесь, что в вашем классе есть метод main. Этот метод является точкой входа в приложение, и без него Java Runtime Environment не сможет выполнить ваш класс. Метод main должен иметь следующую сигнатуру: public static void main(String[] args).

Применяя эти рекомендации, вы сможете успешно запустить свой Java-класс и избежать ошибки «Could not find or load main class».

Java Could Not Find or Load Main Class

When starting your Java application, you may encounter this error:

Error: Could not find or load main class MyClass
Caused by: java.lang.ClassNotFoundException: MyClass
Caused by: java.lang.ClassNotFoundException: MyClass

This error is very common when creating new Java based projects. Whether you’re using Gradle or Maven, Spring Boot or Kafka, chances are you’ve encountered this error before.

Sometimes the error will occur unexpectedly. Sometimes the error is specific to your IDE.

Regardless, fixing the error is easy and it starts with understanding the cause:

What Causes the «Could Not Find or Load Main Class» Error?

This error is thrown whenever Java can’t find or load the main class of your application.

Let’s say you define a class like this:

public class MyClass {
  public static void main(String[] args) {
    System.out.println("My class is working!");
  }
}
  public static void main(String[] args) {
    System.out.println("My class is working!");
  }
}

When running this simple class, you could get the «could not find or load main class» error for several reasons…

1. IDE Configuration Issue

Most IDEs let you configure the starting point for your application. For example, in IntelliJ you can edit configuration to select a main class for running the project.

If you’re running your application through an IDE, make sure that it is configured properly to look for the main class in the right place.

2. Wrong Class Name

Remember that class names must be unique in Java. Furthermore, they are case sensitive…

Let’s say you are running your program from the CLI using the java tool..

java myclass

This will result in the «Could not find or load main class» error because class names are case sensitive.

3. Wrong Extension

When running from the command line, many developers accidentally append an extension like:

java MyClass.java

or

java MyClass.class

The correct way is to run without any extension:

java MyClass

4. Wrong Location

Let’s say your class is part of a package like this:

package com.myproject;
public class  MyClass {
  public static void main(String[] args) {
    System.out.println("My class is working!");
  }
}
public class  MyClass {
  public static void main(String[] args) {
    System.out.println("My class is working!");
  }
}

If you don’t run your class with the fully qualified name AND from the right directory, you will get the «Could not find or load main class» error…

5. Wrong Class Path

The class path is where the JVM looks for classes to load into your program. Sometimes developers provide a specified path like this:

java MyClass -cp /usr/local/path

While the optional -cp argument allows you to specify your own class path, you can easily get the «Could not find or load main class» error if this is incorrect…

How to fix the «Could Not Find or Load Main Class» Error

1. Make sure your IDE is configured properly

Make sure that your IDE has the correct configuration for finding the main class/entry point of your application.

2. Make sure your class name is correct

If you are running your program from the CLI, make sure that you are specifying the right class name without extensions…

java MyClass

3. Make sure you are running your application from the right directory

Make sure you are running your application from the right folder. If your class is part of a package then you must run it from the parent directory….

java com.myproject.MyClass

4. Make sure your class path is correct

Make sure your class path is correct. By default, the class path is the current working directory «.». If you override this with the -cp argument then make sure it’s accurate!

Understanding the Java Error «Could Not Find or Load Main Class»

While this error is self explanatory and easy to fix, it’s worth understanding how Class Loaders work behind the scenes. This gives you a better understanding of why the «Could Not Find or Load Main Class» error happens…

When are Classes Loaded in Java?

Classes are loaded dynamically. This means classes are loaded into memory only when they are needed.

Unlike C++, Java is a dynamically compiled language. This means the language is compiled to machine code while the program is running.

Of course, some classes must be loaded initially when your program starts. The JRE utilizes a native class loader to load the main entry point of your application. From here, class loaders are used to dynamically load (lazy load) classes as they are needed by the application.

The Class Loading Mechanism in Java

Java utilizes a delegation mechanism for loading classes at runtime. There are 3 built-in class loaders used by the JRE at runtime:

1. Bootstrap class loader: This loads the standard runtime classes found in rt.jar

2. Extensions: This loads any extension classes used by the JRE

3. System: This loads classes defined by the application and found on the class path

Each class loader first checks a cache to see if the requested class has already been loaded into memory. If nothing is found in the cache, it delegates the finding of the class to the parent class loader.

This process happens recursively…

If the system class loader can’t find the class, it delegates to the extension class loader.

If the extension class loader can’t find the class, it delegates to the bootstrap class loader.

If the bootstrap class loader can’t find the class, it tells the extension class loader to find it

If the extension class loader can’t find the class, it tells the system class loader to find it

If the system class loader can’t find it, it throws an ClassNotFound exception

This mechanism works to ensure uniqueness, visibility and delegation are applied to the class loading mechanism in Java.

Uniqueness explains the reason why no two classes can have the same name. By keeping class names unique, class loaders can easily find the single representation of a defined class.

Visibility explains the child-parent relationship between class loaders. While children can view parent classes, parents can’t view child classes. This ensures an isolation level needed to create the hierarchy between class loaders.

Delegation explains how the class loaders work together to recursively retrieve a unique class. By delegating to parent classes, class loaders ensure only one representation of a defined class exists.

Java Class Loading Order

1) Class loader searches cache for loaded classes

2) If cache has the class, it is returned. Otherwise, the class loader delegates to parent class to retrieve the class

3) Parent class loaders ultimately delegate to the bootstrap class loader. If the class isn’t found, the bootstrap loader returns responsibility to child loader.

4) Either the system loader finds and loads the class, or a ClassNotFound exception is thrown.

Custom Class Loaders

You can create your own class loaders by extending the ClassLoader class:

public class CustomClassLoader extends ClassLoader { ...

Most developers don’t need to worry about creating custom class loaders. There are times where it makes sense however. Sometimes custom class loaders are used to implementing class versioning. Other custom class loaders allow you to create classes dynamically or switch implementations etc.

Conclusion

The «Could not find or load main class» error is common and easy to fix. Its cause usually has to do with specifying the wrong class name, extension, or class path.

This error can be easily fixed by checking IDE configurations, class path variables, class names, and making sure you’re running the application from the right directory.

The JRE utilizes a class loading mechanism to dynamically load classes into memory. This mechanism relies on a recursive process where class loaders delegate retrieval to parent loaders if they can’t find the class already loaded in memory.

You can create your own custom class loaders for dynamic class creation and versioning.

Your thoughts?

The Java “Could not find or load main class” error is thrown when the JVM fails to find or load the main class while executing a program. It usually occurs when executing a Java program from the command line.

Install the Java SDK to identify and fix these errors

What Causes Error: Could not find or load main class

The «Could not find or load main class» error occurs when the JVM fails to load the main class. This can happen due to various reasons, such as:

  • The class being declared in the incorrect package.
  • The file path of the class not matching the fully qualified name.
  • Incorrectly specified classpath of the application.
  • Missing dependencies from the classpath.
  • Incorrect directory path on the classpath.
  • A typo in the class name.

Error: Could not find or load main class Example

Here’s an example of the Java «Could not find or load main class» error thrown when an incorrect class name is specified during execution:

Here’s an example Java class MyClass.java:

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

Now the above class is compiled using the command line:

$ javac MyClass.java

The compiler generates an executable .class file for MyClass:

$ ls
MyClass.class   MyClass.java

Now if the java command is used to execute the .class file with an incorrect name, the «Could not find or load main class» error is thrown:

$ java Myclass
Error: Could not find or load main class Myclass

The generated .class file has the exact same name as the Java class, which in this case is MyClass.class. Specifying the correct name will execute the program successfully:

$ java MyClass
Hello World

How to Fix Error: Could not find or load main class

There are several ways the «Could not find or load main class» error can occur while executing Java programs. Most of the time, it occurs because of specifying an incorrect class name, class file extension, file path or classpath.

The following tips can be useful to resolve the «Could not find or load main class» error:

  • Using correct class name — The spelling and casing of the class name should be checked when executing the program.
  • Using the class name without the .class extension — The java command expects the class name for executing the program, without the .class extension. Therefore, the following syntax should be used to execute Java classes: java <classname>
  • Using the correct file path — The path to the .class file should be checked and corrected if the error occurs. Remember to use the fully qualified name of the class that is in a package if executing it from outside the directory structure of the package.
  • Correct classpath definition — The classpath should be checked and defined correctly if the error comes up. It can also be specified using the java -cp or -classpath command line arguments.

Track, Analyze and Manage Errors With Rollbar

Managing 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!

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Could not mount the virtual disk ошибка
  • Coremediaerrordomain ошибка 12640
  • Could not initialize steam как исправить ошибку
  • Corellaser ошибка при запуске ver 11
  • Coreldraw попробуйте перезагрузить компьютер ошибка 1

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии