java.lang.ClassNotFoundException when running in IntelliJ IDEA
The error that you get occurs not on complilation, but when you try to run your application. It happens because Java was not able to find Table.class
file inside db
subdirectory of the project output directory (classpath).
It can happen for multiple reasons:
- wrong main class selected in the run/debug configuration
-
Table.java
is excluded from compilation (by accident or intentionally because it contained errors and you wanted to skip it while working on other code) - class not compiled because Build step is excluded from from Before launch steps in the Run/Debug configuration
- project is misconfigured and there is no Source root defined for the directory containing
db
subdirectory -
Table.java
has incorrectpackage
statement or is located/moved to a different package - project path contains a colon
:
on Mac/Linux or semicolon;
on Windows, it's used to separate the classpath and will render the classpath invalid. See this thread for details. Note that Finder on Mac may display colons in the path as slashes. - the jar may not execute if one of the dependent jars is digitally signed since the new artifact will include the partial signature of the dependency. See this answer for more details.
- In project structure make sure you have the right Java version for compile.
- there is a known bug that sometimes a Java project created from the Command Line template doesn't work because
.idea/modules.xml
file references invalid module file nameduntitled104.iml
. Fix the module name manually or create a project from scratch and don't use a template. - on Windows "Beta: Use Unicode UTF-8 for worldwide language support" Region Setting is enabled. See IDEA-247837 for more details and workarounds.
- When IntelliJ IDEA is configured to store module dependencies in Eclipse format source root configuration is lost due to a known bug. Configure the module to use IntelliJ IDEA format dependencies as a workaround.
In a properly configured project and with the correct run/debug configuration everything works just fine:
- the jar may not execute if one of the dependent jars is digitally signed since the new artifact will include the partial signature of the dependency. See this answer for more details.
I must again emphasis the point CrazyCoder has here.
The (Oracle) JVM used to throw a SecurityException when you tried to run a Jar-File containing broken signatures. This made sense from a "What's wrong"-Point of view.
That is no longer the case. They are indeed throwing ClassNotFoundExceptions now - even if the class is right there in the file (no matter if it is in the default package/toplevel or way down in a nested package structure).