We Keep Coding

Exception in thread "main" java.lang.NoClassDefFoundError - Coursera Princeton Algorithm Course

I can see that this question has been asked before, but I have not found previous answers useful - specifically my issue is following Princeton University's 'Algorithms' course on Coursera here and using their algs4.jar file to access ostensibly necessary utilities. I have never used Java before but this seemed like such a good course, I'm trying to muddle through rather than switching to a 'worse' course in a language I know. I have also found a thread specifically on this issue here and a Reddit question here, which were equally as useless as the other questions which had this problem, but not with the Princeton's algs4.jar file.
This is my code, I haven't bothered to finish it but it should run. Before anybody asks, I've commented out everything except the first if (StdIn.isEmpty()) check and it still gives me all the same compiler/interpreter errors, so this is nothing to do with it being half-finished - StdIn.isEmpty() and StdIn.readString() are supposed to be provided by algs4.jar:
import edu.princeton.cs.algs4.StdIn;
import edu.princeton.cs.algs4.StdOut;
import edu.princeton.cs.algs4.StdRandom;
class RandomWord
{
public static void main(String[] args)
{
if (StdIn.isEmpty())
{
System.out.println("Nothing to read.");
return;
}
String curr_selected_word;
double curr_probability = 0.0;
int i = 0;
while (!StdIn.isEmpty())
{
String current_string = StdIn.readString();
System.out.println("> " + current_string);
}
}
}
Following the advice of previous threads, I compile like this:
javac -cp "./algs4.jar" RandomWord.java
Which works fine. Running java RandomWord, I get this large messy error:
Exception in thread "main" java.lang.NoClassDefFoundError: edu/princeton/cs/algs4/StdIn
at RandomWord.main(RandomWord.java:13)
Caused by: java.lang.ClassNotFoundException: edu.princeton.cs.algs4.StdIn
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
... 1 more
The accepted answer on the other question was to reference the .jar file explicitly, like this:
java -cp "C:\Coursera\Algorithms\Part 1\Java Solutions\HelloWorld;C:\Coursera\Algorithms\Part 1\Java Solutions\algs4.jar" RandomWord
Which gives me the exact same error. There is also a comment on the Reddit thread that uses the -classpath instead of -cp flag, which at least gives a different but stranger error:
>java -classpath ./algs4.jar RandomWord
Error: Could not find or load main class RandomWord
Caused by: java.lang.ClassNotFoundException: RandomWord
Putting quotes around the .jar filepath, or providing the absolute filepath, all produce the same error.
I Googled this and predictably it is caused by not having a main entry-point, but... see code above?
Lastly, the installer for the Coursera course apparently installs some Bash commands (see here) called javac-algs4 and java-algs4 which is supposed to sort out all this classpath nonsense for me. So I crack open Bash, and:
>javac-algs4 RandomWord.java
'javac-algs4' is not recognized as an internal or external command,
operable program or batch file.
I have restarted since running the installer. I would add these to my PATH manually, but I don't even know where they are; the C:\Program Files\LIFT-CS folder that their installer installs into only contains a pissing uninstaller. So I'm absolutely losing my rag and at my wits' end after spending over 7 hours just trying to start this course, not even getting stuck on the problems or the content. When will content creators learn we don't want your in-house IDE with no dark mode and libraries that do nothing but rename every function to camel-case?
Anyway, if anyone has encountered this or knows what I could do to fix it, help would be appreciated.

You can try this -
javac -cp .;<insert class path> RandomWord
I was facing the exact same issue, I ran javac -cp .;.lift/algs4.jar RandomWord and it works. (My compiled class was in the same directory as .lift)

This worked for me on a Mac. Copy algs4.jar to the root of your project, then:
javac -cp ".:./algs4.jar" RandomWord.java
java -cp ".:./algs4.jar" RandomWord

How do I pass an additional jar do my java command when running application?

I have a java gradle projectA that references another java gradle projectB, that builds as a lib.
My gradle build configuration seems to be fine, since I can import and use classes from the other project, and it compiles. But when I try to run the application from the command line I get an error...
Exception in thread "main" java.lang.NoClassDefFoundError:
dawcore/SamplerInstrument at DawCLI.main(DawCLI.java:17) Caused by:
java.lang.ClassNotFoundException: dawcore.SamplerInstrument at
java.net.URLClassLoader.findClass(URLClassLoader.java:382) at
java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at
java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 1 more
It seems to be complaining that it can't load the classes in the jar at runtime....which makes sense. But I don't know how to have it successfully load those classes.
my current run command that does not reference the jar, is as follows....
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java -ea -cp "build/classes/main/" DawCLI
Running this gives the initially mentioned error.
I then read the docs on java -cp argument. It says to provide additional classpath directories, to separate them by semicolon.
I susequently updated my run command to be as follows....
/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java -ea -cp "build/classes/main/;../DawCore/build/libs/DawCore.jar" DawCLI
This gives me the following error....
Error: Could not find or load main class DawCLI
My main function is as follows..
import dawcore.*;
public class DawCLI {
public static void main (String [] args) throws IOException {
SamplerInstrument samplerkick = new SamplerInstrument();
}
}
According to the docs I seem to be doing this correctly, but am still getting errors. Any insight on this would be greatly appreciated!
Thanks

The solution was to replace the delimiting semi-colon with a colon instead. Even though the first line of the javadocs on -cp command indicate that you should use a semi-colon.
This could be because I am running on linux and those docs indicate Windows.
https://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html

ClassNotFoundException while replacing java 6 rmi w/ java 8 [duplicate]

The following method :
private void startServer() { // snippet that starts the server on the local machine
try {
RemoteMethodImpl impl = new RemoteMethodImpl();
Naming.rebind( "Illusive-Server" , impl );
}catch(Exception exc) {
JOptionPane.showMessageDialog(this, "Problem starting the server", "Error", JOptionPane.ERROR_MESSAGE);
System.out.println(exc);
}
}
throws this exception :java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: Interfaces.RemoteMethodIntf
When i start my project, i am greeted with the message in JOptionPane saying problem starting the server and then the above exception. What could be the reason for this ?
I don't understand why does the last statement of exception says class not found exc when i have imported the right packages

There are four cases of this exception.
When exporting: you didn't run 'rmic' and you didn't take the steps described in the preamble to the Javadoc for UnicastRemoteObject to make it unnecessary.
When binding: the Registry doesn't have the stub or the remote interface or something they depend on on its classpath.
when looking up: the client does't have these things on its classpath.
When calling a remote method: you either sent something to the server of a class not present on its CLASSPATH, or received something from the server (including an exception) of a class not on your CLASSPATH: in both cases possibly a derived class or interface implementation of a class or interface mentioned in the remote interface's method signature.
This is case 2. The Registry can't find the named class.
There are several solutions:
Start the Registry with a CLASSPATH that includes the relevant JARs or directories.
Start the Registry in your server JVM, via LocateRegistry.createRegistry().
Use dynamic stubs, as described in the preamble to the Javadoc of UnicastRemoteObject. However you may then still run into the same problem with the remote interface itself or a class that it depends on, in which case 1-3 above still apply to that class/those classes.
Ensure that case (4) above doesn't occur.
Use the codebase feature. This is really a deployment option and IMO something to be avoided at the initial development stage.

Remote Server Error:RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: mathInterface
The error very simple to solve to be perform following steps:
For example your java file consider D drive
Start rmiregistry D drive( example D:\start rmiregistry)then don't start rmiregistry on the other drives, it will yield the above error
(Wherever your file is, start rmiregistry)

I will try to explain it as better as possible what I did:
1st. I declared the classpath variable like follow:
set classpath=%classpath%
set classpath=C:\compiler
set classpath=C:\compiler\libro\cap07\rmi\hello\Hello.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Server.java
set classpath=C:\compiler\libro\cap07\rmi\hello\Client.java
(All in one lineset:
set classpath=%classpath%;C:\compiler;C:\compiler\libro\cap07\rmi\hello\Hello.java;C:\compiler\libro\cap07\rmi\hello\Server.java;C:\compiler\libro\cap07\rmi\hello\Client.java)
(I'm not sure if the .java files were nesesary, but I also wrote them for doubts).
2nd. I compilered with the line javac -d C:\compiler Hello.java Server.java Client.java. Where C:\compiler is the root directory like src on Eclipse IDE.
3rd. I ran the start rmiregistry line. (and don´t matter where you run it, it's the same).
4th. I ran:
start java -classpath C:\compiler -Djava.rmi.server.codebase=file:C:\compiler/ libro.cap07.rmi.hello.Server
You already know C:\compiler, but you need define packages address on the last to that the command can find the .class files. Open any .java file and copy the package address without packages sentense. You will see when you open the src directory (in my case C:\compiler), you find all directory sequence created. When this command line is created correctly, no matter where you will run it, C:, D:, src, anywhere it wil run.
5th. And finally, I ran the Client class with:
java -classpath C:\compiler libro.cap07.rmi.hello.Client
In conclusion, if the classpath variable won't created or it's to created wrong or the sentence of 4th point is not addressed well the JVM throws the same or similar error. Search there!
(Sorry my english).

You can launch rmiregistry from anywhere but you have to make sure that the compiled classes are already in your classpath. For example:-
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>set classpath=%classpath%;E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes <ENTER>
E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes>c: <ENTER>
C:\>rmiregistry
And the above should work fine.
In general, if you launch rmiregistry from the root location of the compiled classes (above example it is E:\ARMSRemoteUpdater\WebContent\WEB-INF\classes), that will work because . (dot - current directory) is already set in your classpath.
But as soon as you remove . (dot - current directory) from your classpath, the above working condition will also fail.
Hope I have explained in details.

I got this same issue, and a different solution worked for me. I was running two different IntelliJ projects, with a copy of the interface in each project. One of them was in a package, and the other one wasn't, and that was what was causing this error.
Solutions:
Make sure the interface copies aren't in a package.
Make sure the interface copies have the exact same package name.

cobertura-instrument.sh fails to instrument jar file with java.lang.NoClassDefFoundError: net.sourceforge.cobertura.instrument.InstrumentMain

I'm trying to instrument jar file (from Spacewalk project) so I can measure code coverage of mine testing, but it is failing:
# /opt/cobertura-2.1.1/cobertura-instrument.sh --datafile /tmp/out /usr/share/rhn/lib/rhn.jar
Exception in thread "main" java.lang.NoClassDefFoundError: net.sourceforge.cobertura.instrument.InstrumentMain
Caused by: java.lang.ClassNotFoundException: net.sourceforge.cobertura.instrument.InstrumentMain
at java.net.URLClassLoader.findClass(URLClassLoader.java:432)
at java.lang.ClassLoader.loadClass(ClassLoader.java:676)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:642)
Could not find the main class: net.sourceforge.cobertura.instrument.InstrumentMain. Program will exit.
I have tried to provide one random class (in the ideal state I want to instrument all of them) from that jar as well, but with same result:
# jar tf rhn.jar | tail
org/cobbler/CobblerConnection.class
[...]
# /opt/cobertura-2.1.1/cobertura-instrument.sh --datafile /tmp/out /usr/share/rhn/lib/rhn.jar org.cobbler.CobblerConnection
I'm pretty sure I'm just missing something what it is trying to tell me.
I'm using cobertura-2.1.1 downloaded from SourceForge and extracted into /opt, running on Red Hat Enterprise Linux 6.

OK, this was simple:
# dos2unix /opt/cobertura-2.1.1/cobertura-instrument.sh
also it is missing bash shebang (#!/bin/bash), so you might need to add it to the beginning of the file (I do not know why it worked for me even without that).

Java: Use of bootclasspath preventing H2 driver from being found

If I build my own, tinkered version of rt.jar (called my-rt.jar) from the Oracle JDK 7 sources and hook it in with the bootclasspath mechanism, like this,
$ java -Xbootclasspath/p:/path/to/my-rt.jar -cp /path/to/h2-1.3.174.jar main
then, I can't even load the H2 driver at the beginning of my application:
// Application's main.java
public class main {
public static void main(String[] args) {
// ...
Class.forName("org.h2.Driver"); // Line 145
}
}
The above results in the following exception:
Exception in thread "main" java.lang.ClassNotFoundException: org/h2/Driver
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at main.main(main.java:415)
However, if I remove the -Xbootclasspath/p switch and with everything else the same as before, I can load the driver fine, and the rest of application too works fine too.
So, is there anything peculiar going on inside the initialization of a JDBC driver (such as H2's) that's preventing me from using the bootclasspath mechanism? Or, is there anything peculiar about the bootclasspath mechanism that it won't allow the loading of a JDBC driver like H2?
I'm out of things to try. For example,
I've even re-built the H2 driver from its sources and made sure that both my application and the driver are using the identical version of javac.
I've tried the above both from Eclipse and from command-line.
I've tried it on 2 different machines.
All yield the same exception.
Btw, my tinkered my-rt.jar has a very simple edit to it: It simply adds a public static int counter to java.lang.Object. Before the Class.forName(...) line above, I'm able to verify that I can indeed print the value of counter when the bootclasspath switch is enabled.
The strange thing is, even if I comment out this counter field in java.lang.Object but continue prepending my-rt.jar (that is as good as the original rt.jar, only recompiled andn prepended), even then I cannot get the H2 driver to be found/loaded!
(I've posted this on the H2 google group too but getting no response there. Maybe, those folks don't think this is an H2 problem, so I'm asking here.)

I've nailed it. Here's what I did.
I first prepended the original rt.jar to the original rt.jar, like so:
$ java -Xbootclasspath/p:/path/to/orig/rt.jar -cp /path/to/h2-1.3.174.jar main
And the exception disappeared! This clearly told me that the bootclasspath/p mechanism was no way interfering with the loading of the H2 driver.
So, I then unjarred the original rt.jar and diff'ed it with the unjarred contents of my-rt.jar, I found around a whopping 8000 files missing from my-rt.jar:
$ wc -l *.list
11285 my-rt.jar.list
19059 rt.jar.list
30344 total
So, obviously, my-rt.jar that I built from the official src.zip had tons of stuff missing from it. No wonder, H2 driver was having loading troubles.
To further confirm, this time I copied over only my tinkered java/lang/Object.class to the unjarred contents of the original rt.jar, and lo and behold, the H2 driver continued to load just fine.
Thus, the name src.zip is a terrible misnomer. Because it does not have everything needed to build rt.jar, it should be called partial-src.zip (or, something like that) instead.