By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,963 Members | 1,749 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,963 IT Pros & Developers. It's quick & easy.

java.lang.NoClassDefFoundError

P: n/a
Lem
I get the error
Exception in thread "main" java.lang.NoClassDefFoundError

when I type java app2 in the command prompt. I've tried moving to the jre
directory and typed java c:\app2\app2, but it gives me the same exception.
What could be the problem?

Thanks in advance,
Lem
Jul 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Lem
There is nothing wrong with the code, it compiles fine, moreover the sdk
examples do not work as well.

Lem
Jul 17 '05 #2

P: n/a
In article <bg**********@nobel.pacific.net.sg>, Lem wrote:
There is nothing wrong with the code, it compiles fine, moreover the sdk
examples do not work as well.


If the SDK examples also don't work, then that seems to point back to a
CLASSPATH problem. To verify that this is the issue, you can try
invoking java using the cp switch to tell it explicitly where to find the class.
For example, if your app2.class is in a directory called c:\mydir, then
you could try

java -cp c:\mydir app2

(assuming the cp switch works the same in the Windows implementation -
I'm working from a linux box). If that works, then we at least know
that it's a classpath problem.

Mel Roman
me*@melroman.net
Jul 17 '05 #3

P: n/a
Lem
Thanks, the -cp switch worked, one thing I don't understand though, I ran my
app from its directory, shouldn't the jre start searching there first?

Thanks in advacnce,
Lem
"Mel Roman" <me*@melroman.net> wrote in message
news:IO*******************@news04.bloor.is.net.cab le.rogers.com...
In article <bg**********@nobel.pacific.net.sg>, Lem wrote:
There is nothing wrong with the code, it compiles fine, moreover the sdk
examples do not work as well.

If the SDK examples also don't work, then that seems to point back to a
CLASSPATH problem. To verify that this is the issue, you can try
invoking java using the cp switch to tell it explicitly where to find the

class. For example, if your app2.class is in a directory called c:\mydir, then
you could try

java -cp c:\mydir app2

(assuming the cp switch works the same in the Windows implementation -
I'm working from a linux box). If that works, then we at least know
that it's a classpath problem.

Mel Roman
me*@melroman.net

Jul 17 '05 #4

P: n/a
In article <bg**********@nobel.pacific.net.sg>, Lem wrote:
Thanks, the -cp switch worked, one thing I don't understand though, I ran my
app from its directory, shouldn't the jre start searching there first?
--


At least this confirms that it's a classpath problem. As you say,
java should search the current directory (as well as those directories
specified in your CLASSPATH environment variable) to find your
app2.class file. Specifically, if your app2.class file is in your
c:\mydir directory, then you should be able to run app2 like this:

cd c:\mydir
java app2

You've already confirmed that you've tried this without success. I
can't explain why that isn't working for you. Perhaps one of our more
experienced brethren can offer an explanation.

At any rate, another poster recommended that you check and (if
necessary) modify your CLASSPATH. You'll probably want to define a file
hierarchy for storing all of your compiled *.class files (organized by
package) and put the top-level directory of that hierarchy in your CLASSPATH.
This link in the Sun tutorial talks about this:

http://java.sun.com/docs/books/tutor...gingfiles.html

Good luck,
Mel Roman
me*@melroman.net
Jul 17 '05 #5

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mel Roman wrote:

<snip>
cd c:\mydir
java app2

You've already confirmed that you've tried this without success. I
can't explain why that isn't working for you. Perhaps one of our
more experienced brethren can offer an explanation.

<snip>

Hi,
I have a pretty good idea of what the problem MIGHT be. The virtual
machine doesn't search in the current directory for class files,
unless the CLASSPATH variable is not set, or tells it to. That is, if
you must set CLASSPATH, set it so that the first item is . like this:

If your CLASSPATH needs to include "c:\mylib.jar" for some reason, and
it is set like so:

SET CLASSPATH=c:\mylib.jar

replace it with this:

SET CLASSPATH=.;c:\mylib.jar

On the other hand, if you don't need CLASSPATH, get rid of it and
everything should also be fine.

- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/JFI/wxczzJRavJYRAqTdAKCRr4fO/sk6my29ZV/HijfWHf47jQCg+WcF
du0UvkOHQImkzTfVWRbRAPk=
=AVqY
-----END PGP SIGNATURE-----
Jul 17 '05 #6

P: n/a
In article <Rw********************@news1.telusplanet.net>, Chris wrote:

I have a pretty good idea of what the problem MIGHT be. The virtual
machine doesn't search in the current directory for class files,
unless the CLASSPATH variable is not set, or tells it to. That is, if
you must set CLASSPATH, set it so that the first item is . like this:


Thanks for the input, Chris. I was playing with this a little while ago
myself. I didn't initially have any CLASSPATH variable, and executing
java myapp from within myapp's current directory worked just fine. Even
after setting my CLASSPATH to /home/mel/java, I can still always execute
an app from the current directory (outside of the CLASSPATH). Your
comments make me wonder if different java implementations behave differently.

Lem: Try doing what Chris says and see if that allows you to execute
"normally" (without the -cp switch) from the current directory. I'd be
interested in hearing your answer.

-

Mel Roman
me*@melroman.net
Jul 17 '05 #7

P: n/a
Lem
Thanks, it works =)

Lem
"Mel Roman" <me*@melroman.net> wrote in message
news:98*******************@news04.bloor.is.net.cab le.rogers.com...
In article <Rw********************@news1.telusplanet.net>, Chris wrote:

I have a pretty good idea of what the problem MIGHT be. The virtual
machine doesn't search in the current directory for class files,
unless the CLASSPATH variable is not set, or tells it to. That is, if
you must set CLASSPATH, set it so that the first item is . like this:
Thanks for the input, Chris. I was playing with this a little while ago
myself. I didn't initially have any CLASSPATH variable, and executing
java myapp from within myapp's current directory worked just fine. Even
after setting my CLASSPATH to /home/mel/java, I can still always execute
an app from the current directory (outside of the CLASSPATH). Your
comments make me wonder if different java implementations behave

differently.
Lem: Try doing what Chris says and see if that allows you to execute
"normally" (without the -cp switch) from the current directory. I'd be
interested in hearing your answer.

-

Mel Roman
me*@melroman.net

Jul 17 '05 #8

P: n/a
On Sun, 27 Jul 2003 20:40:06 +0800, "Lem" <hj***@pacific.net.sg>
wrote:
I get the error
Exception in thread "main" java.lang.NoClassDefFoundError

when I type java app2 in the command prompt. I've tried moving to the jre
directory and typed java c:\app2\app2, but it gives me the same exception.
What could be the problem?

Thanks in advance,
Lem


You didn't say what environment, but your example above uses
DOS/Windows directory syntax. Sun's Java CL (if that's what you are
using) has Unix CL semantics ... try prefixing ".\" (current
directory) to the name of the class file you want to run, eg., "java
..\app2".

If that doesn't work, try using forward slashes "/" in the filespec.
There is (or use to be) an environment setting for the JRE that tells
it which to expect ... sorry, I don't remember what the setting is/was
- I only had to use it once long ago.

George

Jul 17 '05 #9

P: n/a
In article <3f***********************@news.dial.pipex.com>, Peter Bradley wrote:
Hi guys and gals,

I've never understood $CLASSPATH and packages and friends - but I had the
same problem, which is why I'm reading this thread.


I can't be sure, but I suspect that this Chris' comments may apply here
again. What is the value of your CLASSPATH variable? As Chris said,
clearing it may force java to look in your current directory.
--

Mel Roman
me*@melroman.net
Jul 17 '05 #10

P: n/a
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<posted & mailed>

Peter Bradley wrote:
Hi guys and gals,

I've never understood $CLASSPATH and packages and friends - but I
had the same problem, which is why I'm reading this thread.

After looking at the replies (and remembering some odd experiences
I'd had with a previous excursion into Javaland) I tried calling the
program from the directory above where it resides.

To illustrate. Here's the code:

<codeextract>

package ConnectorJTest;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class LoadDriver {

public static void main(String[] args) {
try {
Class.forName("com.mysql.jdbc.Driver").newInstance ();
System.out.println("Success!");
} catch (Exception ex) {
// Handle the error
System.out.println("Failure!");
}
}
}

</codeextract>

The program is in
/home/peter/connector_j_test/ConnectorJTest/LoadDriver.class

Now, if I call the program by going to the ConnectorJTest and doing:

java LoadDriver

I get:

<output>

peter@linux:~/connector_j_test/ConnectorJTest> java LoadDriver
Exception in thread "main" java.lang.NoClassDefFoundError:
LoadDriver (wrong name: ConnectorJTest/LoadDriver)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java :502)
at
java.security.SecureClassLoader.defineClass(Secure ClassLoader.java:123) at
java.net.URLClassLoader.defineClass(URLClassLoader .java:250)
at
java.net.URLClassLoader.access$100(URLClassLoader. java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java: 193) at
java.security.AccessController.doPrivileged(Native Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.j ava:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 99) at
sun.misc.Launcher$AppClassLoader.loadClass(Launche r.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:2 55) at
java.lang.ClassLoader.loadClassInternal(ClassLoade r.java:315)
</output>

And if I try the fully qualified name from the same directory, I
get:

<output>

peter@linux:~/connector_j_test/ConnectorJTest> java
ConnectorJTest.LoadDriver
Exception in thread "main" java.lang.NoClassDefFoundError:
ConnectorJTest/LoadDriver

</output>

However if I move up a directory and give the fully qualified name,
I get:

<output>
peter@linux:~/connector_j_test> java ConnectorJTest.LoadDriver
Success!

</output>

Any explanation (preferably rational, though :) ) would be
gratefully received

Cheers

Peter


Hi,
After working with Java for a while, I seem to understand the
CLASSPATH/packages thing. Here goes:

Every class has a package. If one isn't specified when it's created,
it's in the root package, but it still "has" a package.

If you create the following file in the current directory:

package com.somecompany.test;

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

and run javac on it directly:
javac Test.java
It produces a file called Test.class in the current directory, which
fails utterly when you try to run it. See, each piece of the package
name is supposed to correspond to a physical directory name in the
filesystem. When you run javac as above, it outputs the class file in
the current directory. If, on the other hand, you were to put the
above source into a file com/somecompany/test/Test.java, staying in
the same directory (not descending in deeper), compiling it would
create com/somecompany/test/Test.class, which you could then run by
typing "java com.somecompany.test.Test". The idea is that by using
the filesystem like this, packages are useful. If two companies make
two classes with the same name, they put them in different packages.
Thus, inside the VM, everyone is sure which class is being referred
to. By using directories in the filesystem, both classes can be put
in "the same place" but they won't overwrite each other.

If you type in "java com.somecompany.test.Test", here's what happens:

The JVM needs to find the class. Ignoring the jre/lib/ext directory
for the time being, we'll assume a CLASSPATH variable set to
/home/me/java. The JVM does this internally:

REALPATH=$CLASSPATH/$PACKAGENAME/$CLASSNAME
Thus, the real path is
/home/me/java/com/somecompany/test/Test.class
which exists.

Why it doesn't work moving into that directory and just typing "java
Test", is because the class file has the package name that it was
meant to be inside of embedded when it's compiled. The JVM detects
that although it seems to be able to find the class, it must be the
wrong file because by typing the above command line, you're asking
for a class in the root package, and the file it found isn't in the
root package. It assumes something is wrong.

Now, personally, I don't actually even have the CLASSPATH set. This
means the JVM defaults to "." as its value. Thus:

java com.somecompany.test.Test

loads

../com/somecompany/test/Test.class

which contains the package name inside the file:

com.somecompany.test

which the JVM checks against the command line, and sees that it
matches, so everything is good. Thus, I can just invoke any class I
need by changing to its root directory (which, of course, isn't
necessarily the directory containing the class file--in the case of
packages, it's the directory containing the highest-level package
name).

For libraries, I find, easier than downloading the JAR file and adding
it to the CLASSPATH, just put it into the jre/lib/ext directory.
Every JAR file in jre/lib/ext is automatically put in the classpath.
Thus, if I use the MySQL connector, and the JVM tries to find this
class:

com.mysql.jdbc.Driver

it takes the classpath element like this (filename shortened):

/usr/java/j2sdk1.4.2/jre/lib/ext/mysql.jar

appends the names just like I described previously, producing this
physical path:

/usr/java/j2sdk1.4.2/jre/lib/ext/mysql.jar/com/mysql/jdbc/Driver

which looks ridiculous, since it describes a directory inside a file,
but, what happens, is that inside the mysql.jar file is a zipped
directory called com, which contains a directory called mysql, etc.
etc. etc. and everything works.

Basically, just remember:

- - When invoking a class that is in a package, you have to include the
package name on the command line.

- - When invoking a class that is in a package, the class file needs to
be contained in a directory structure matching the package name, OFF
OF whatever element in CLASSPATH is relevant. If there's a package
name, the class file isn't going to be right in the directory, it'll
be in a subdirectory.

- - To include a JAR file, just put the path to the JAR itself in the
CLASSPATH, and the file acts like a root directory in terms of
packaging. It doesn't work just putting the directory containing the
JAR in your classpath, primarily because that would imply the name of
the JAR file is part of the package name (good luck trying to get the
".jar" part to go into the package name without being converted into
a subdirectory <VBG>)

Rational explanation? Lunatic rambling? Probably both. Hope it helped
though :)

- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KYnBwxczzJRavJYRAvGGAKCy9PNnjXfk5jtxHm9utwrGBZXbzg CglmIS
+gbxA2LvEiioKieWoT9jsxY=
=s0Na
-----END PGP SIGNATURE-----
Jul 17 '05 #11

P: n/a
Chris,

If you are ever unable to get development work, go into teaching.
Great! I see it all now. Couldn't be clearer.

Many thanks.

Peter

Chris wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<posted & mailed>

Peter Bradley wrote:

Hi guys and gals,

I've never understood $CLASSPATH and packages and friends - but I
had the same problem, which is why I'm reading this thread.

After looking at the replies (and remembering some odd experiences
I'd had with a previous excursion into Javaland) I tried calling the
program from the directory above where it resides.

To illustrate. Here's the code:

<codeextract>

package ConnectorJTest;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class LoadDriver {

public static void main(String[] args) {
try {
Class.forName("com.mysql.jdbc.Driver").newInstance ();
System.out.println("Success!");
} catch (Exception ex) {
// Handle the error
System.out.println("Failure!");
}
}
}

</codeextract>

The program is in
/home/peter/connector_j_test/ConnectorJTest/LoadDriver.class

Now, if I call the program by going to the ConnectorJTest and doing:

java LoadDriver

I get:

<output>

peter@linux:~/connector_j_test/ConnectorJTest> java LoadDriver
Exception in thread "main" java.lang.NoClassDefFoundError:
LoadDriver (wrong name: ConnectorJTest/LoadDriver)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java :502)
at


java.security.SecureClassLoader.defineClass(Secure ClassLoader.java:123)
at
java.net.URLClassLoader.defineClass(URLClassLoader .java:250)
at
java.net.URLClassLoader.access$100(URLClassLoader. java:54)
at java.net.URLClassLoader$1.run(URLClassLoader.java: 193) at
java.security.AccessController.doPrivileged(Native Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.j ava:186)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 99) at


sun.misc.Launcher$AppClassLoader.loadClass(Launche r.java:265)
at java.lang.ClassLoader.loadClass(ClassLoader.java:2 55) at


java.lang.ClassLoader.loadClassInternal(ClassLoade r.java:315)
</output>

And if I try the fully qualified name from the same directory, I
get:

<output>

peter@linux:~/connector_j_test/ConnectorJTest> java
ConnectorJTest.LoadDriver
Exception in thread "main" java.lang.NoClassDefFoundError:
ConnectorJTest/LoadDriver

</output>

However if I move up a directory and give the fully qualified name,
I get:

<output>
peter@linux:~/connector_j_test> java ConnectorJTest.LoadDriver
Success!

</output>

Any explanation (preferably rational, though :) ) would be
gratefully received

Cheers

Peter

Hi,
After working with Java for a while, I seem to understand the
CLASSPATH/packages thing. Here goes:

Every class has a package. If one isn't specified when it's created,
it's in the root package, but it still "has" a package.

If you create the following file in the current directory:

package com.somecompany.test;

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

and run javac on it directly:
javac Test.java
It produces a file called Test.class in the current directory, which
fails utterly when you try to run it. See, each piece of the package
name is supposed to correspond to a physical directory name in the
filesystem. When you run javac as above, it outputs the class file in
the current directory. If, on the other hand, you were to put the
above source into a file com/somecompany/test/Test.java, staying in
the same directory (not descending in deeper), compiling it would
create com/somecompany/test/Test.class, which you could then run by
typing "java com.somecompany.test.Test". The idea is that by using
the filesystem like this, packages are useful. If two companies make
two classes with the same name, they put them in different packages.
Thus, inside the VM, everyone is sure which class is being referred
to. By using directories in the filesystem, both classes can be put
in "the same place" but they won't overwrite each other.

If you type in "java com.somecompany.test.Test", here's what happens:

The JVM needs to find the class. Ignoring the jre/lib/ext directory
for the time being, we'll assume a CLASSPATH variable set to
/home/me/java. The JVM does this internally:

REALPATH=$CLASSPATH/$PACKAGENAME/$CLASSNAME
Thus, the real path is
/home/me/java/com/somecompany/test/Test.class
which exists.

Why it doesn't work moving into that directory and just typing "java
Test", is because the class file has the package name that it was
meant to be inside of embedded when it's compiled. The JVM detects
that although it seems to be able to find the class, it must be the
wrong file because by typing the above command line, you're asking
for a class in the root package, and the file it found isn't in the
root package. It assumes something is wrong.

Now, personally, I don't actually even have the CLASSPATH set. This
means the JVM defaults to "." as its value. Thus:

java com.somecompany.test.Test

loads

./com/somecompany/test/Test.class

which contains the package name inside the file:

com.somecompany.test

which the JVM checks against the command line, and sees that it
matches, so everything is good. Thus, I can just invoke any class I
need by changing to its root directory (which, of course, isn't
necessarily the directory containing the class file--in the case of
packages, it's the directory containing the highest-level package
name).

For libraries, I find, easier than downloading the JAR file and adding
it to the CLASSPATH, just put it into the jre/lib/ext directory.
Every JAR file in jre/lib/ext is automatically put in the classpath.
Thus, if I use the MySQL connector, and the JVM tries to find this
class:

com.mysql.jdbc.Driver

it takes the classpath element like this (filename shortened):

/usr/java/j2sdk1.4.2/jre/lib/ext/mysql.jar

appends the names just like I described previously, producing this
physical path:

/usr/java/j2sdk1.4.2/jre/lib/ext/mysql.jar/com/mysql/jdbc/Driver

which looks ridiculous, since it describes a directory inside a file,
but, what happens, is that inside the mysql.jar file is a zipped
directory called com, which contains a directory called mysql, etc.
etc. etc. and everything works.

Basically, just remember:

- - When invoking a class that is in a package, you have to include the
package name on the command line.

- - When invoking a class that is in a package, the class file needs to
be contained in a directory structure matching the package name, OFF
OF whatever element in CLASSPATH is relevant. If there's a package
name, the class file isn't going to be right in the directory, it'll
be in a subdirectory.

- - To include a JAR file, just put the path to the JAR itself in the
CLASSPATH, and the file acts like a root directory in terms of
packaging. It doesn't work just putting the directory containing the
JAR in your classpath, primarily because that would imply the name of
the JAR file is part of the package name (good luck trying to get the
".jar" part to go into the package name without being converted into
a subdirectory <VBG>)

Rational explanation? Lunatic rambling? Probably both. Hope it helped
though :)

- --
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KYnBwxczzJRavJYRAvGGAKCy9PNnjXfk5jtxHm9utwrGBZXbzg CglmIS
+gbxA2LvEiioKieWoT9jsxY=
=s0Na
-----END PGP SIGNATURE-----


Jul 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.