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(
        at Method)
        at java.lang.ClassLoader.loadClass(
        at sun.misc.Launcher$AppClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
        at java.lang.ClassLoader.loadClassInternal(

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

Lagos, Nigeria
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Move to directory called 'packages' and do

javac classxmp\

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

javac -classpath c:\packages classxmp\

or wherever your packages directory is. The previous method is probably better though
PMI ACP® Project Management

Prepare for the PMI Agile Certified Practitioner (PMI-ACP)® exam, which formally recognizes your knowledge of agile principles and your skill with agile techniques.

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

Mick BarryJava DeveloperCommented:
Just add c:\packages to your classpath
Mick BarryJava DeveloperCommented:
> java -classpath . packages.classxmp.Trial

You are also using the wrong command, try:

java -classpath c:\packages classxmp.Trial

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Mick BarryJava DeveloperCommented:
> 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.
Mick BarryJava DeveloperCommented:
> javac -classpath c:\packages classxmp\

All that typing is not really necessary, you can simply go to the directory c:\packages\classwmp and use:


Your two classes are member of classxmp package, so when you compile them, should use
    javac -d .     and    javac -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.
Mick BarryJava DeveloperCommented:
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.
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.


  package com.example.stuff.test;
  class me ...

would assume that the class resides in the following directory:


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
  /> java -cp /usr/bob

Windows example: [root] = c:\usr\bob
C:\usr\bob> java
c:\usr\bob> java -cp c:\usr\bob

Mick BarryJava DeveloperCommented:
> Note that the CLASSPATH is pretty much deprecated

Can you point to a reference stating that.

Heading "Description," second paragraph, starting with the third sentence.
Also take a look at the fourth paragraph, second sentence.

Mick BarryJava DeveloperCommented:
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.
>>Can you point to a reference stating that.

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
> 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 :-)
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...
Less pain for beginners = fewer easy points for us answering classpath problems ;-)
hehe ;-)
Mick BarryJava DeveloperCommented:
> 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 :)
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.
Mick BarryJava DeveloperCommented:
> The first thing Java beginners want is to get HelloWorld working right away

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.
Mick BarryJava DeveloperCommented:
> 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.
Well - next time it happens we'll do some anecdotal research ;-)
Mick BarryJava DeveloperCommented:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.