fox4life
asked on
Setting Classpaths and importing packages
I am new to java programming and currently i am using j2sdk1.4.2 compiler. Each time I try compilling or running a program, i encounter several errors that has to do with classpath setting.
I wrote this two classes:
this class resides in c:\packages\classxmp
// Calc class
package classxmp;
public class Calc
{
public int area(int x, int y)
{
int sol;
sol = x*y;
return sol;
}
}
this class also resides in c:\packages\classxmp
// Trial Class
package classxmp;
import classxmp.*;
public class Trial
{
int x = 5;
int y = 6;
int a;
public void main(String args[]) {
Calc dl = new Calc();
a = dl.area(x,y);
System.out.println("area is: "+a);
}
}
after compilling these two classes, each time I try running the program by issuing this command.
C:\>c:\j2sdk1.4.2\bin\java
I get this error message below.
Exception in thread "main" java.lang.NoClassDefFoundE
at java.lang.ClassLoader.defi
at java.lang.ClassLoader.defi
at java.security.SecureClassL
3)
at java.net.URLClassLoader.de
at java.net.URLClassLoader.ac
at java.net.URLClassLoader$1.
at java.security.AccessContro
at java.net.URLClassLoader.fi
at java.lang.ClassLoader.load
at sun.misc.Launcher$AppClass
at java.lang.ClassLoader.load
at java.lang.ClassLoader.load
Please help me, I don't understand what this means.
this classpath thing is driving me nuts.
Raymond
Lagos, Nigeria
Rayasadu@yahoo.com
I wrote this two classes:
this class resides in c:\packages\classxmp
// Calc class
package classxmp;
public class Calc
{
public int area(int x, int y)
{
int sol;
sol = x*y;
return sol;
}
}
this class also resides in c:\packages\classxmp
// Trial Class
package classxmp;
import classxmp.*;
public class Trial
{
int x = 5;
int y = 6;
int a;
public void main(String args[]) {
Calc dl = new Calc();
a = dl.area(x,y);
System.out.println("area is: "+a);
}
}
after compilling these two classes, each time I try running the program by issuing this command.
C:\>c:\j2sdk1.4.2\bin\java
I get this error message below.
Exception in thread "main" java.lang.NoClassDefFoundE
at java.lang.ClassLoader.defi
at java.lang.ClassLoader.defi
at java.security.SecureClassL
3)
at java.net.URLClassLoader.de
at java.net.URLClassLoader.ac
at java.net.URLClassLoader$1.
at java.security.AccessContro
at java.net.URLClassLoader.fi
at java.lang.ClassLoader.load
at sun.misc.Launcher$AppClass
at java.lang.ClassLoader.load
at java.lang.ClassLoader.load
Please help me, I don't understand what this means.
this classpath thing is driving me nuts.
Raymond
Lagos, Nigeria
Rayasadu@yahoo.com
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You shouldn't really have classes under your bin directory if that's where they are. Delete them and start again. With the command line mentioned earlier. You don't need to import classes in the same package so delete
>>import classxmp.*;
>>import classxmp.*;
Just add c:\packages to your classpath
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> I don't understand what this means.
It means it cannot find the specified class.
> this classpath thing is driving me nuts.
The classpath is used by the class loader to locate classes. It is a list of directories and jars files, that works similarly to the PATH variable for locating executables. When a class is requested, each entry in the classpath is used to search for the specified class.
It means it cannot find the specified class.
> this classpath thing is driving me nuts.
The classpath is used by the class loader to locate classes. It is a list of directories and jars files, that works similarly to the PATH variable for locating executables. When a class is requested, each entry in the classpath is used to search for the specified class.
> javac -classpath c:\packages classxmp\Calc.java
All that typing is not really necessary, you can simply go to the directory c:\packages\classwmp and use:
javac Calc.java
All that typing is not really necessary, you can simply go to the directory c:\packages\classwmp and use:
javac Calc.java
Your two classes are member of classxmp package, so when you compile them, should use
javac Calc.java -d . and javac Trial.java -d . or
javac *.java -d .
You will get a folder called 'classxmp' and the .class files.
Then, run the class with this command
java classxmp.Trial
All above commands should be executed at the directory wherever .java files are there.
javac Calc.java -d . and javac Trial.java -d . or
javac *.java -d .
You will get a folder called 'classxmp' and the .class files.
Then, run the class with this command
java classxmp.Trial
All above commands should be executed at the directory wherever .java files are there.
That'll result in a pretty messy directory structure which will quickly become hard to manage.
Easier to put the class files in the same directory as the source, or in a seperate directory structure.
And if you want to avoid using "-classpath c:\packages" then just add that directory to your CLASSPATH environment variable.
Easier to put the class files in the same directory as the source, or in a seperate directory structure.
And if you want to avoid using "-classpath c:\packages" then just add that directory to your CLASSPATH environment variable.
Note that the CLASSPATH is pretty much deprecated, as it was unwieldy to begin with.
For jars and the like, the best solution is to put them in the ${j2sdk}\jre\lib\ext and ${j2re}\lib\ext directories.
-------------------
FOX4LIFE: the package designator assumes that you are at the top of the hirearchy when you invoke it.
So,
package com.example.stuff.test;
class me ...
would assume that the class resides in the following directory:
[root]/
com/
example/
stuff/
test/
me.class
When you invoke me.class, you MUST either be in the [root] directory, OR point to it on your classpath.
For example, suppose [root] was /usr/bob. The following are valid:
/user/bob> java com.example.stuff.test.me
or
/> java -cp /usr/bob com.example.stuff.test.me
Windows example: [root] = c:\usr\bob
C:\usr\bob> java com.example.stuff.test.me
or
c:\usr\bob> java -cp c:\usr\bob com.example.stuff.test.me
For jars and the like, the best solution is to put them in the ${j2sdk}\jre\lib\ext and ${j2re}\lib\ext directories.
-------------------
FOX4LIFE: the package designator assumes that you are at the top of the hirearchy when you invoke it.
So,
package com.example.stuff.test;
class me ...
would assume that the class resides in the following directory:
[root]/
com/
example/
stuff/
test/
me.class
When you invoke me.class, you MUST either be in the [root] directory, OR point to it on your classpath.
For example, suppose [root] was /usr/bob. The following are valid:
/user/bob> java com.example.stuff.test.me
or
/> java -cp /usr/bob com.example.stuff.test.me
Windows example: [root] = c:\usr\bob
C:\usr\bob> java com.example.stuff.test.me
or
c:\usr\bob> java -cp c:\usr\bob com.example.stuff.test.me
> Note that the CLASSPATH is pretty much deprecated
Can you point to a reference stating that.
Can you point to a reference stating that.
http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/classpath.html
Heading "Description," second paragraph, starting with the third sentence.
Also take a look at the fourth paragraph, second sentence.
Cheers
Heading "Description," second paragraph, starting with the third sentence.
Also take a look at the fourth paragraph, second sentence.
Cheers
I don't think that implies that the CLASSPATH is deprecated.
If you have a class hierarchy in a specific directory it is a lot easier to specify that directory in the CLASSPATH env var than having to cd to a directory or enter it on the command line every time you want to use that class. Gets even more annoying when you are compiling code.
If you have a class hierarchy in a specific directory it is a lot easier to specify that directory in the CLASSPATH env var than having to cd to a directory or enter it on the command line every time you want to use that class. Gets even more annoying when you are compiling code.
>>Can you point to a reference stating that.
LOL - i was waiting for you to wade in on this issue ;-) Listening...
LOL - i was waiting for you to wade in on this issue ;-) Listening...
>>Note that the CLASSPATH is pretty much deprecated
Let's imagine you'd said 'pretty much to be avoided' TallBoy
Let's imagine you'd said 'pretty much to be avoided' TallBoy
> For jars and the like, the best solution is to put them in the ${j2sdk}\jre\lib\ext and ${j2re}\lib\ext directories.
Gah!!! My pet peeve!!!
Doing this can just lead you to a world of pain (especially in a proper development environment)...
If you put all the jars you download, or test, or just even look at in the lib/ext directory, when you come to deploy your app on another server, or distribute your app, or upgrade your JVM, you will have no idea which jar is used, by what, or for what...
If you have ever gone to a developer's machine when they are on holiday, and a client is asking for a demonstration off site, only to find the script to run the huge application is:
java Main
when you KNOW it uses a specific version of Xerces, and other libraries, you are left having to copy them all from lib/ext...
This is not a pretty, or fun state of affairs...
Practice with the classpath... it can be a pain, but when you sort it out, the scripts to run your apps self document which libraries they use...
Start your java apps with a batch file or a script file
Compile your apps with an IDE or ant
Sorry for the rant...
I have just had this problem too many times... :-(
Tim :-)
Gah!!! My pet peeve!!!
Doing this can just lead you to a world of pain (especially in a proper development environment)...
If you put all the jars you download, or test, or just even look at in the lib/ext directory, when you come to deploy your app on another server, or distribute your app, or upgrade your JVM, you will have no idea which jar is used, by what, or for what...
If you have ever gone to a developer's machine when they are on holiday, and a client is asking for a demonstration off site, only to find the script to run the huge application is:
java Main
when you KNOW it uses a specific version of Xerces, and other libraries, you are left having to copy them all from lib/ext...
This is not a pretty, or fun state of affairs...
Practice with the classpath... it can be a pain, but when you sort it out, the scripts to run your apps self document which libraries they use...
Start your java apps with a batch file or a script file
Compile your apps with an IDE or ant
Sorry for the rant...
I have just had this problem too many times... :-(
Tim :-)
My personal take (which is known to many) is that beginners shouldn't be even told that such a thing as CLASSPATH exists ;-)
That's a bit of a "science education" way of looking at things ;-)
Like at A-Level physics, you realise that GCSE physics was all lies and over-simplifications ;-)
Still, you are probably right...
I just don't like the lib/ext method...
Like at A-Level physics, you realise that GCSE physics was all lies and over-simplifications ;-)
Still, you are probably right...
I just don't like the lib/ext method...
Less pain for beginners = fewer easy points for us answering classpath problems ;-)
hehe ;-)
> Less pain for beginners = fewer easy points for us answering classpath problems ;-)
Educating beginners up front will save a lot of future q's being asked :)
Educating beginners up front will save a lot of future q's being asked :)
Well I'm not sure where they get their starting advice from or what the advisors are saying. The first thing Java beginners want is to get HelloWorld working right away - they don't need to be wrestling with classpaths. They should be told how to get more information about classpaths later if they have more sophisticated requirements.
> The first thing Java beginners want is to get HelloWorld working right away
I think they move past HelloWorld pretty quickly.
I think they move past HelloWorld pretty quickly.
Don't think so - that's their first brush with classpath misery. Don't forget - they break it because they set the classpath incorrectly - becuase they've been told they need one.
> Don't think so - that's their first brush with classpath misery.
Rarely, it generally happens as soon as there app involves >1 class.
> they break it because they set the classpath incorrectly
Not unless they are taught incorrectly.
> becuase they've been told they need one.
You don't tell them they need one, you teach them how it works.
Rarely, it generally happens as soon as there app involves >1 class.
> they break it because they set the classpath incorrectly
Not unless they are taught incorrectly.
> becuase they've been told they need one.
You don't tell them they need one, you teach them how it works.
Well - next time it happens we'll do some anecdotal research ;-)
javac classxmp\Calc.java
and like for the other. The java bin directory should be on your PATH varaiable