Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1188
  • Last Modified:

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 -classpath . packages.classxmp.Trial
 
I get this error message below.

Exception in thread "main" java.lang.NoClassDefFoundError: packages/classxmp/Trial (wrong name: classxmp/Trial)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
3)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)

Please help me, I don't understand what this means.
this classpath thing is driving me nuts.


Raymond
Lagos, Nigeria
Rayasadu@yahoo.com
0
fox4life
Asked:
fox4life
  • 11
  • 11
  • 3
  • +2
2 Solutions
 
CEHJCommented:
Move to directory called 'packages' and do

javac classxmp\Calc.java

and like for the other. The java bin directory should be on your PATH varaiable
0
 
CEHJCommented:
You could also stay where you are and do

javac -classpath c:\packages classxmp\Calc.java

or wherever your packages directory is. The previous method is probably better though
0
 
CEHJCommented:
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
CEHJCommented:
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.*;

0
 
objectsCommented:
Just add c:\packages to your classpath
0
 
objectsCommented:
> java -classpath . packages.classxmp.Trial

You are also using the wrong command, try:

java -classpath c:\packages classxmp.Trial

0
 
objectsCommented:
> 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.
0
 
objectsCommented:
> 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


0
 
gnoonCommented:
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.
0
 
objectsCommented:
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.
0
 
TallBoyCommented:
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

0
 
objectsCommented:
> Note that the CLASSPATH is pretty much deprecated

Can you point to a reference stating that.
0
 
TallBoyCommented:
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
0
 
objectsCommented:
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.
0
 
CEHJCommented:
>>Can you point to a reference stating that.

LOL - i was waiting for you to wade in on this issue ;-) Listening...
0
 
CEHJCommented:
>>Note that the CLASSPATH is pretty much deprecated

Let's imagine you'd said 'pretty much to be avoided' TallBoy
0
 
TimYatesCommented:
> 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 :-)
0
 
CEHJCommented:
My personal take (which is known to many) is that beginners shouldn't be even told that such a thing as CLASSPATH exists ;-)
0
 
TimYatesCommented:
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...
0
 
CEHJCommented:
Less pain for beginners = fewer easy points for us answering classpath problems ;-)
0
 
TimYatesCommented:
hehe ;-)
0
 
objectsCommented:
> 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 :)
0
 
CEHJCommented:
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.
0
 
objectsCommented:
> The first thing Java beginners want is to get HelloWorld working right away

I think they move past HelloWorld pretty quickly.
0
 
CEHJCommented:
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.
0
 
objectsCommented:
> 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.
0
 
CEHJCommented:
Well - next time it happens we'll do some anecdotal research ;-)
0
 
objectsCommented:
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 11
  • 11
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now