java.lang.NoClassDefFoundError

[Lem]

I get the error
Exception in thread "main" java.lang.NoCla ssDefFoundError

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

[Lem]

Re: java.lang.NoCla ssDefFoundError

There is nothing wrong with the code, it compiles fine, moreover the sdk
examples do not work as well.

Lem

[Mel Roman]

Re: java.lang.NoCla ssDefFoundError

In article <bg0ogg$qui$1@n obel.pacific.ne t.sg>, Lem wrote:[color=blue]
> There is nothing wrong with the code, it compiles fine, moreover the sdk
> examples do not work as well.
>[/color]

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
mel@melroman.ne t

[Lem]

Re: java.lang.NoCla ssDefFoundError

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" <mel@melroman.n et> wrote in message
news:IORUa.9749 2$zwL.34427@new s04.bloor.is.ne t.cable.rogers. com...[color=blue]
> In article <bg0ogg$qui$1@n obel.pacific.ne t.sg>, Lem wrote:[color=green]
> > There is nothing wrong with the code, it compiles fine, moreover the sdk
> > examples do not work as well.
> >[/color]
>
> 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[/color]
class.[color=blue]
> 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
> mel@melroman.ne t[/color]

[Mel Roman]

Re: java.lang.NoCla ssDefFoundError

In article <bg1vmm$38h$1@n obel.pacific.ne t.sg>, Lem wrote:[color=blue]
> 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?
>--[/color]

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/tutorial/java/interpack/managingfiles.html

Good luck,


Mel Roman
mel@melroman.ne t

[Chris]

Re: java.lang.NoCla ssDefFoundError

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

Mel Roman wrote:

<snip>[color=blue]
> 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.[/color]
<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.j ar" for some reason, and
it is set like so:

SET CLASSPATH=c:\my lib.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/wxczzJRavJYRAqT dAKCRr4fO/sk6my29ZV/HijfWHf47jQCg+W cF
du0UvkOHQImkzTf VWRbRAPk=
=AVqY
-----END PGP SIGNATURE-----

[Mel Roman]

Re: java.lang.NoCla ssDefFoundError

In article <Rw2Va.42260$Ma .9720126@news1. telusplanet.net >, Chris wrote:[color=blue]
>
>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:[/color]

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
mel@melroman.ne t

[Lem]

Re: java.lang.NoCla ssDefFoundError

Thanks, it works =)

Lem


"Mel Roman" <mel@melroman.n et> wrote in message
news:988Va.1031 18$zwL.1812@new s04.bloor.is.ne t.cable.rogers. com...[color=blue]
> In article <Rw2Va.42260$Ma .9720126@news1. telusplanet.net >, Chris wrote:[color=green]
> >
> >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:[/color]
>
> 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[/color]
differently.[color=blue]
>
> 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
> mel@melroman.ne t[/color]

[George Neuner]

Re: java.lang.NoCla ssDefFoundError

On Sun, 27 Jul 2003 20:40:06 +0800, "Lem" <hjlem@pacific. net.sg>
wrote:
[color=blue]
>I get the error
>Exception in thread "main" java.lang.NoCla ssDefFoundError
>
>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
>[/color]

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

[Mel Roman]

Re: java.lang.NoCla ssDefFoundError

In article <3f298fcd$0$184 96$cc9e4d1f@new s.dial.pipex.co m>, Peter Bradley wrote:[color=blue]
> 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.[/color]

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
mel@melroman.ne t

[Chris]

Re: java.lang.NoCla ssDefFoundError

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

<posted & mailed>

Peter Bradley wrote:
[color=blue]
> 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.Connec tion;
> import java.sql.Driver Manager;
> import java.sql.SQLExc eption;
>
> public class LoadDriver {
>
> public static void main(String[] args) {
> try {
> Class.forName(" com.mysql.jdbc. Driver").newIns tance();
> System.out.prin tln("Success!") ;
> } catch (Exception ex) {
> // Handle the error
> System.out.prin tln("Failure!") ;
> }
> }
> }
>
> </codeextract>
>
> The program is in
> /home/peter/connector_j_tes t/ConnectorJTest/LoadDriver.clas s
>
> Now, if I call the program by going to the ConnectorJTest and doing:
>
> java LoadDriver
>
> I get:
>
> <output>
>
> peter@linux:~/connector_j_tes t/ConnectorJTest> java LoadDriver
> Exception in thread "main" java.lang.NoCla ssDefFoundError :
> LoadDriver (wrong name: ConnectorJTest/LoadDriver)
> at java.lang.Class Loader.defineCl ass0(Native Method)
> at java.lang.Class Loader.defineCl ass(ClassLoader .java:502)
> at
>[/color]
java.security.S ecureClassLoade r.defineClass(S ecureClassLoade r.java:123)[color=blue]
> at
> java.net.URLCla ssLoader.define Class(URLClassL oader.java:250)
> at
> java.net.URLCla ssLoader.access $100(URLClassLo ader.java:54)
> at java.net.URLCla ssLoader$1.run( URLClassLoader. java:193) at
> java.security.A ccessController .doPrivileged(N ative Method)
> at
> java.net.URLCla ssLoader.findCl ass(URLClassLoa der.java:186)
> at java.lang.Class Loader.loadClas s(ClassLoader.j ava:299) at
>[/color]
sun.misc.Launch er$AppClassLoad er.loadClass(La uncher.java:265 )[color=blue]
> at java.lang.Class Loader.loadClas s(ClassLoader.j ava:255) at
>[/color]
java.lang.Class Loader.loadClas sInternal(Class Loader.java:315 )[color=blue]
>
> </output>
>
> And if I try the fully qualified name from the same directory, I
> get:
>
> <output>
>
> peter@linux:~/connector_j_tes t/ConnectorJTest> java
> ConnectorJTest. LoadDriver
> Exception in thread "main" java.lang.NoCla ssDefFoundError :
> ConnectorJTest/LoadDriver
>
> </output>
>
> However if I move up a directory and give the fully qualified name,
> I get:
>
> <output>
> peter@linux:~/connector_j_tes t> java ConnectorJTest. LoadDriver
> Success!
>
> </output>
>
> Any explanation (preferably rational, though :) ) would be
> gratefully received
>
> Cheers
>
> Peter[/color]

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.prin tln("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=$CLASS PATH/$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/KYnBwxczzJRavJY RAvGGAKCy9PNnjX fk5jtxHm9utwrGB ZXbzgCglmIS
+gbxA2LvEiioKie WoT9jsxY=
=s0Na
-----END PGP SIGNATURE-----

[Peter Bradley]

Re: java.lang.NoCla ssDefFoundError

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:[color=blue]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> <posted & mailed>
>
> Peter Bradley wrote:
>
>[color=green]
>>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:
>>
>><codeextrac t>
>>
>>package ConnectorJTest;
>>
>>import java.sql.Connec tion;
>>import java.sql.Driver Manager;
>>import java.sql.SQLExc eption;
>>
>>public class LoadDriver {
>>
>> public static void main(String[] args) {
>> try {
>> Class.forName(" com.mysql.jdbc. Driver").newIns tance();
>> System.out.prin tln("Success!") ;
>> } catch (Exception ex) {
>> // Handle the error
>> System.out.prin tln("Failure!") ;
>> }
>> }
>>}
>>
>></codeextract>
>>
>>The program is in
>>/home/peter/connector_j_tes t/ConnectorJTest/LoadDriver.clas s
>>
>>Now, if I call the program by going to the ConnectorJTest and doing:
>>
>>java LoadDriver
>>
>>I get:
>>
>><output>
>>
>>peter@linux :~/connector_j_tes t/ConnectorJTest> java LoadDriver
>>Exception in thread "main" java.lang.NoCla ssDefFoundError :
>>LoadDriver (wrong name: ConnectorJTest/LoadDriver)
>> at java.lang.Class Loader.defineCl ass0(Native Method)
>> at java.lang.Class Loader.defineCl ass(ClassLoader .java:502)
>> at
>>[/color]
>
> java.security.S ecureClassLoade r.defineClass(S ecureClassLoade r.java:123)
>[color=green]
>> at
>> java.net.URLCla ssLoader.define Class(URLClassL oader.java:250)
>> at
>> java.net.URLCla ssLoader.access $100(URLClassLo ader.java:54)
>> at java.net.URLCla ssLoader$1.run( URLClassLoader. java:193) at
>> java.security.A ccessController .doPrivileged(N ative Method)
>> at
>> java.net.URLCla ssLoader.findCl ass(URLClassLoa der.java:186)
>> at java.lang.Class Loader.loadClas s(ClassLoader.j ava:299) at
>>[/color]
>
> sun.misc.Launch er$AppClassLoad er.loadClass(La uncher.java:265 )
>[color=green]
>> at java.lang.Class Loader.loadClas s(ClassLoader.j ava:255) at
>>[/color]
>
> java.lang.Class Loader.loadClas sInternal(Class Loader.java:315 )
>[color=green]
>></output>
>>
>>And if I try the fully qualified name from the same directory, I
>>get:
>>
>><output>
>>
>>peter@linux :~/connector_j_tes t/ConnectorJTest> java
>>ConnectorJTes t.LoadDriver
>>Exception in thread "main" java.lang.NoCla ssDefFoundError :
>>ConnectorJTes t/LoadDriver
>>
>></output>
>>
>>However if I move up a directory and give the fully qualified name,
>>I get:
>>
>><output>
>>peter@linux :~/connector_j_tes t> java ConnectorJTest. LoadDriver
>>Success!
>>
>></output>
>>
>>Any explanation (preferably rational, though :) ) would be
>>gratefully received
>>
>>Cheers
>>
>>Peter[/color]
>
>
> 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.prin tln("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=$CLASS PATH/$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/KYnBwxczzJRavJY RAvGGAKCy9PNnjX fk5jtxHm9utwrGB ZXbzgCglmIS
> +gbxA2LvEiioKie WoT9jsxY=
> =s0Na
> -----END PGP SIGNATURE-----[/color]