I am trying to call a non-module class from a module class. I have created a folder structure
moduledemo > allclasses > moduleC > packageC > MyMethods.class
is the path to my module class file
moduledemo > moduleC > packageC > MyMethods.java
and
moduledemo > nomodule > packageD > DemoNoModule.class
is the no module class that I am calling from MyMethods.java
I am able to compile the DemoNoModule file. I am able to compile MyMethods.java into allclasses folder moduleC.
When I am running MyMethods I am getting error moduleC not found. Can anyone update? I am using the following command to run
java --module-path allclasses -m moduleC/packageC.MyMethods
Both files code -> Non-Module Class
package packageD;
public class DemoNoModule {
public void showD() {
System.out.println("this is show of D in No Module");
}
}
Module class calling class
package packageC;
import packageD.*;
public class MyMethods {
public static void main(String s[]) {
DemoNoModule d=new DemoNoModule();
d.showD();
}
}
Module info in module C
module moduleC {
exports packageC;
}
On one hand, the moduleC(mind improving naming?) is a named module.
While on another, the "no module class" termed by you is nothing but as stated by Alan a class present on the classpath. The classes present on the classpath during the execution are part of an unnamed module in JPMS.
Quoting the documentation further:-
The unnamed module exports all of its packages. This enables
flexible migration... It does not, however, mean
that code in a named module can access types in the unnamed module. A
named module cannot, in fact, even declare a dependence upon the
unnamed module.
This is intentional to preserve the reliable configuration in the module system. As stated further :
If a package is defined in both a named module and the unnamed module
then the package in the unnamed module is ignored. This preserves
reliable configuration even in the face of the chaos of the class
path, ensuring that every module still reads at most one module
defining a given package.
Still, to make use of a class from the unnamed module in your named module moduleC, you can follow the suggestion of making use of the flag to add ALL-UNNAMED module to be read by modules on the module path using the
following command:
--add-reads <source-module>=<target-module> // moduleC=ALL-UNNAMED
As a special case, if the <target-module> is ALL-UNNAMED then
readability edges will be added from the source module to all present
and future unnamed modules, including that corresponding to the class
path.
PS: Do take into consideration the highlighted portion(above) of the documentation as you do so.
Also note the long-term solution would be to revise your design here, for which you can plan to move your code in the class DemoNoModule into an explicit module or package it separately to be converted into an automatic module.
Java 9 programs are supposed to be modular. That is how I understood jigsaw in JDK-9. So, IMHO, you'll have to 'wrap' your packageD in another module and in the module-info for moduleC write requires moduleD. Also moduleD should export packageD.
ALL-UNNAMED is added for backward compatibility, and I suppose it will be removed in some point of Java evolution.
I've tried both the examples in Oracle's Java Tutorials. They both compile fine, but at run time, both come up with this error:
Exception in thread "main" java.lang.NoClassDefFoundError: graphics/shapes/Square
at Main.main(Main.java:7)
Caused by: java.lang.ClassNotFoundException: graphics.shapes.Square
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more
I think I might have the Main.java file in the wrong folder.
Here is the directory hierarchy:
graphics
├ Main.java
├ shapes
| ├ Square.java
| ├ Triangle.java
├ linepoint
| ├ Line.java
| ├ Point.java
├ spaceobjects
| ├ Cube.java
| ├ RectPrism.java
And here is Main.java:
import graphics.shapes.*;
import graphics.linepoint.*
import graphics.spaceobjects.*;
public class Main {
public static void main(String args[]) {
Square s = new Square(2, 3, 15);
Line l = new Line(1, 5, 2, 3);
Cube c = new Cube(13, 32, 22);
}
}
What am I doing wrong here?
UPDATE
After I put put the Main class into the graphics package (I added package graphics; to it), set the classpath to "_test" (folder containing graphics), compiled it, and ran it using java graphics.Main (from the command line), it worked.
Really late UPDATE #2
I wasn't using Eclipse (just Notepad++ and the JDK), and the above update solved my problem. However, it seems that many of these answers are for Eclipse and IntelliJ IDEA, but they have similar concepts.
After you compile your code, you end up with .class files for each class in your program. These binary files are the bytecode that Java interprets to execute your program. The NoClassDefFoundError indicates that the classloader (in this case java.net.URLClassLoader), which is responsible for dynamically loading classes, cannot find the .class file for the class that you're trying to use.
Your code wouldn't compile if the required classes weren't present (unless classes are loaded with reflection), so usually this exception means that your classpath doesn't include the required classes. Remember that the classloader (specifically java.net.URLClassLoader) will look for classes in package a.b.c in folder a/b/c/ in each entry in your classpath. NoClassDefFoundError can also indicate that you're missing a transitive dependency of a .jar file that you've compiled against and you're trying to use.
For example, if you had a class com.example.Foo, after compiling you would have a class file Foo.class. Say for example your working directory is .../project/. That class file must be placed in .../project/com/example, and you would set your classpath to .../project/.
Side note: I would recommend taking advantage of the amazing tooling that exists for Java and JVM languages. Modern IDEs like Eclipse and IntelliJ IDEA and build management tools like Maven or Gradle will help you not have to worry about classpaths (as much) and focus on the code! That said, this link explains how to set the classpath when you execute on the command line.
I'd like to correct the perspective of others on NoClassDefFoundError.
NoClassDefFoundError can occur for multiple reasons like:
ClassNotFoundException -- .class not found for that referenced class irrespective of whether it is available at compile time or not(i.e base/child class).
Class file located, but Exception raised while initializing static variables
Class file located, Exception raised while initializing static blocks
In the original question, it was the first case which can be corrected by setting CLASSPATH to the referenced classes JAR file or to its package folder.
What does it mean by saying "available in compile time"?
The referenced class is used in the code. E.g.: Two classes, A and B (extends A). If B is referenced directly in the code, it is available at compile time, i.e., A a = new B();
What does it mean by saying "not available at compile time"?
The compile time class and runtime class are different, i.e., for example base class is loaded using classname of child class for example
Class.forName("classname")
E.g.: Two classes, A and B (extends A). Code has
A a = Class.forName("B").newInstance();
If you got one of these errors while compiling and running:
NoClassDefFoundError
Error: Could not find or load main class hello
Exception in thread "main" java.lang.NoClassDefFoundError:javaTest/test/hello
(wrong name: test/hello)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
-------------------------- Solution -----------------------
The problem is mostly in packages organization. You should arrange your classes in folders properly regarding to the package classifications in your source code.
On compiling process, use this command:
javac -d . [FileName.java]
To run the class, please use this command:
java [Package].[ClassName]
NoClassDefFoundError means that the class is present in the classpath at Compile time, but it doesn't exist in the classpath at Runtime.
If you're using Eclipse, make sure you have the shapes, linepoints and the spaceobjects as entries in the .classpath file.
java.lang.NoClassDefFoundError
indicates that something was found at compile time, but not at run time. Maybe you just have to add it to the classpath.
NoClassDefFoundError in Java:
Definition:
NoClassDefFoundError will come if a class was present during compile time but not available in java classpath during runtime. Normally you will see below line in log when you get NoClassDefFoundError:
Exception in thread "main" java.lang.NoClassDefFoundError
Possible Causes:
The class is not available in Java Classpath.
You might be running your program using jar command and class was not defined in manifest file's ClassPath attribute.
Any start-up script is overriding Classpath environment variable.
Because NoClassDefFoundError is a subclass of java.lang.LinkageError it can also come if one of it dependency like native library may not available.
Check for java.lang.ExceptionInInitializerError in your log file. NoClassDefFoundError due to the failure of static initialization is quite common.
If you are working in J2EE environment than the visibility of Class among multiple Classloader can also cause java.lang.NoClassDefFoundError, see examples and scenario section for detailed discussion.
Possible Resolutions:
Verify that all required Java classes are included in the application’s classpath. The most common mistake is not to include all the necessary classes, before starting to execute a Java application that has dependencies on some external libraries.
The classpath of the application is correct, but the Classpath environment variable is overridden before the application’s execution.
Verify that the aforementioned ExceptionInInitializerError does not appear in the stack trace of your application.
Resources:
3 ways to solve java.lang.NoClassDefFoundError in Java J2EE
java.lang.NoClassDefFoundError – How to solve No Class Def Found Error
The no class definition exception occurs when the intended class is not found in the class path.
At compile time class: Class was generated from the Java compiler, but somehow at run time the dependent class is not found.
Let’s go through one simple example:
public class ClassA{
public static void main(String args[]){
// Some gibberish code...
String text = ClassB.getString();
System.out.println("Text is: " + text);
}
}
public class ClassB{
public static String getString(){
return "Testing some exception";
}
}
Now let's assume that the above two Java source code are placed in some folder, let's say "NoClassDefinationFoundExceptionDemo"
Now open a shell (assuming Java is already being set up correctly)
Go to folder "NoClassDefinationFoundExceptionDemo"
Compile Java source files
javac ClassB
javac ClassA
Both files are compiled successfully and generated class files in the same folder as ClassA.class and ClassB.class
Now since we are overriding ClassPath to the current working director, we execute the following command
java -cp . ClassA
and it worked successfully and you will see the output on the screen
Now let's say, you removed ClassB.class file from the present directory.
And now you execute the command again.
java -cp . ClassA Now it will greet you with NoClassDefFoundException. As ClassB which is a dependency for ClassA is not found in the classpath (i.e., the present working directory).
If your project is in a package like com.blahcode and your class is called Main, the compiled files may be output in a directory structure like ./out/com/blahcode/Main.class. This is especially true for IntelliJ IDEA.
When trying to run from a shell or cmd, you need to cd to that which contains com as a sub-directory.
cd out
java -classpath . com.blahcode.Main
I have faced with the problem today. I have an Android project and after enabling multidex the project wouldn't start anymore.
The reason was that I had forgotten to call the specific multidex method that should be added to the Application class and invoked before everything else.
MultiDex.install(this);
Follow this tutorial to enable multidex correctly. https://developer.android.com/studio/build/multidex.html
You should add these lines to your Application class
#Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
After working on a NetBeans project for many months, I suddenly got the NoClassDefFoundError message shortly after getting a "Low Memory" alert. Doing a Clean rebuild didn't help, but closing NetBeans altogether and reopening the project there were no error reports.
This answer is specific to a java.lang.NoClassDefFoundError happening in a service:
My team recently saw this error after upgrading an rpm that supplied a service. The rpm and the software inside of it had been built with Maven, so it seemed that we had a compile time dependency that had just not gotten included in the rpm.
However, when investigating, the class that was not found was in the same module as several of the classes in the stack trace. Furthermore, this was not a module that had only been recently added to the build. These facts indicated it might not be a Maven dependency issue.
The eventual solution: Restart the service!
It appears that the rpm upgrade invalidated the service's file handle on the underlying JAR file. The service then saw a class that had not been loaded into memory, searched for it among its list of jar file handles, and failed to find it because the file handle that it could load the class from had been invalidated. Restarting the service forced it to reload all of its file handles, which then allowed it to load that class that had not been found in memory right after the rpm upgrade.
For my project, what solved the issue was that Chrome browser and chromedriver were not compatibles. I had a very old version of the driver that could not even open the browser. I just downloaded the latest version of both and problem solved.
How did I discover the issue? Because I ran my project using the Selenium native Firefox driver with an old version of FF included with my application. I realized the problem was incompatibility between browser and driver.
Hope this can help anyone with a similar issue as mine, that generated this same Error Message.
If you are "starting" a class from a JAR file, make sure to start with the JAR full path. For example, (if your "main class" is not specified in Manifest):
java -classpath "./dialer.jar" com.company.dialer.DialerServer
And if there are any dependencies, such dependencies to other JAR files, you can solve such a dependency
either by adding such JAR files (full path to each JAR file) to the class path. For example,
java -classpath "./libs/phone.jar;./libs/anotherlib.jar;./dialer.jar" com.company.dialer.DialerServer
or by editing the JAR manifest by adding "dependency JAR filess" to the manifest. Such a manifest file might look like:
Manifest-Version: 1.0
Class-Path: phone.jar anotherlib.jar
Build-Jdk-Spec: 1.8
Main-Class: com.company.dialer.DialerServer
or (if you are a developer having source code) you can use Maven to prepare a manifest for you by adding to the *.pom file:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>com.company.dialer.DialerServer</mainClass>
<!-- Workaround for Maven bug #MJAR-156 (https://jira.codehaus.org/browse/MJAR-156) -->
<useUniqueVersions>false</useUniqueVersions>
</manifest>
</archive>
</configuration>
</plugin>
Please note that the above example uses ; as a delimiter in classpath (it is valid for the Windows platform). On Linux, replace ; by :.
For example,
java -classpath ./libs/phone.jar:./libs/anotherlib.jar:./dialer.jar
com.company.dialer.DialerServer
I'm developing an Eclipse based application also known as RCP (Rich Client Platform).
And I have been facing this problem after refactoring (moving one class from an plugIn to a new one).
Cleaning the project and Maven update didn't help.
The problem was caused by the Bundle-Activator which haven't been updated automatically. Manual update of the Bundle-Activator under MANIFEST.MF in the new PlugIn has fixed my problem.
If you are using more than one module, you should have
dexOptions {
preDexLibraries = false
}
in your build file.
I had the same issue with my Android development using Android studio. Solutions provided are general and did not help me (at least for me).
After hours of research, I found the following solution and it may help to Android developers who are doing development using Android Studio.
Modify the setting as below:
Preferences → Build, Execution, Deployment → Instant Run → *uncheck the first option.
With this change I am up and running.
My two cents in this chain:
Ensure that the classpath contains full paths (/home/user/lib/some_lib.jar instead of ~/lib/some_lib.jar) otherwise you can still face NoClassDefFoundError error.
Don't use test classes outside the module
I do not have a solution, just another flavour of the "present at compilation, absent at run time" case.
I was trying to use a very convenient method from a JUnit test class from another test class which resides in a different module. That's a no-no, since test code is not part of the packaged jar, but I didn't realize because it appears visible for the user class from within Eclipse.
My solution was to place the method in a existing utilities class that is part of the production code.
I get NoClassFoundError when classes loaded by the runtime class loader cannot access classes already loaded by the Java rootloader. Because the different class loaders are in different security domains (according to Java) the JVM won't allow classes already loaded by the rootloader to be resolved in the runtime loader address space.
Run your program with 'java -javaagent:tracer.jar [YOUR 'java' ARGUMENTS]'
It produces output showing the loaded class, and the loader environment that loaded the class. It's very helpful tracing why a class cannot be resolved.
// ClassLoaderTracer.java
// From: https://blogs.oracle.com/sundararajan/entry/tracing_class_loading_1_5
import java.lang.instrument.*;
import java.security.*;
// manifest.mf
// Premain-Class: ClassLoadTracer
// jar -cvfm tracer.jar manifest.mf ClassLoaderTracer.class
// java -javaagent:tracer.jar [...]
public class ClassLoadTracer
{
public static void premain(String agentArgs, Instrumentation inst)
{
final java.io.PrintStream out = System.out;
inst.addTransformer(new ClassFileTransformer() {
public byte[] transform(ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
String pd = (null == protectionDomain) ? "null" : protectionDomain.getCodeSource().toString();
out.println(className + " loaded by " + loader + " at " + new java.util.Date() + " in " + pd);
// dump stack trace of the thread loading class
Thread.dumpStack();
// we just want the original .class bytes to be loaded!
// we are not instrumenting it...
return null;
}
});
}
}
It happened to me in Android Studio.
The solution that worked for me: just restart Android Studio.
Check that if you have a static handler in your class. If so, please be careful, cause static handler only could be initiated in thread which has a looper, the crash could be triggered in this way:
Firstly, create the instance of class in a simple thread and catch the crash.
Then call the field method of Class in main thread, you will get the NoClassDefFoundError.
Here is the test code:
public class MyClass{
private static Handler mHandler = new Handler();
public static int num = 0;
}
In your onCreate method of the Main activity, add the test code part:
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//test code start
new Thread(new Runnable() {
#Override
public void run() {
try {
MyClass myClass = new MyClass();
} catch (Throwable e) {
e.printStackTrace();
}
}
}).start();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
MyClass.num = 3;
// end of test code
}
There is a simple way to fix it using a handlerThread to the init handler:
private static Handler mHandler;
private static HandlerThread handlerThread = new HandlerThread("newthread");
static {
handlerThread.start();
mHandler = new Handler(handlerThread.getLooper(), mHandlerCB);
}
One source of error for this exception could stem from inconsistent definitions for Proguard, e.g. a missing
-libraryJars "path.to.a.missing.jar.library".
This explains why compilation and running works fine, given that the JAR file is there, while clean and build fails. Remember to define the newly added JAR libraries in the ProGuard setup!
Note that error messages from ProGuard are really not up to standard, as they are easily confused with similar Ant messages arriving when the JAR file is not there at all. Only at the very bottom will there be a small hint of ProGuard in trouble. Hence, it is quite logical to start searching for traditional classpath errors, etc., but this will be in vain.
Evidently, the NoClassDefFound exception will be the results when running, e.g., the resulting executable JAR file built and based on a lack of ProGuard consistency. Some call it ProGuard "Hell".
I use the FileSync plugin for Eclipse, so I can live debug on Tomcat. I received NoClassFoundError, because I had added a sync entry for the bin directory in the Eclipse workspace => classes in the metadata for Tomcat, but I hadn't also added a folder sync for the extlib directory in Eclipse =>
C:\Users\Stuart\eclipse-workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\webapps\myApp\WEB-INF\lib
If you recently added multidex support in Android Studio like this:
// To support MultiDex
implementation 'com.android.support:multidex:1.0.1'
So your solution is just extend from MultiDexApplication instead of Application:
public class MyApp extends MultiDexApplication {
In my environment, I encountered this issue in a unit test. After appending one library dependency to *.pom, that's fixed.
Example:
Error message:
java.lang.NoClassDefFoundError: com/abc/def/foo/xyz/Iottt
POM content:
<dependency>
<groupId>com.abc.def</groupId>
<artifactId>foo</artifactId>
<scope>test</scope>
</dependency>
I got this error after a Git branch change. For the specific case of Eclipse, there were missed lines in the .settings directory for the org.eclipse.wst.common.component file. As you can see below.
Restoring the project dependencies with Maven install would help.
If you are using gradlew, go to ./gradle/wrapper/gradle-wrapper.properties and change distributionUrl to the correct version of Gradle.
If you are using JDK14, try:
distributionUrl=https\://services.gradle.org/distributions/gradle-6.3-bin.zip
For Meteor or Cordova users,
It can be caused by the Java version you use. For Meteor and Cordova, stick with version 8 for now.
Check available Java versions /usr/libexec/java_home -V and look for the path name for Java version 8
Set the path for Java version 8
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home
Check if it is done
echo $JAVA_HOME
Go on and continue coding.
The Java 11 + Eclipse solution:
This solution is for you if you are not using module-info.java in your Eclipse project, and you added the JAR files manually instead of using Maven/Gradle.
Right click project → Build path → Configure build path → libraries tab
Remove the problematic JAR file from the modulepath
Add the JAR file to the classpath
More information is in
In Eclipse, what is the difference between modulepath and classpath?.
I deleted the folder "buid" and "out", and the IDE rebuild again this folders with updated content files.