Trouble Running Program from Command Prompt

Hey guys, this question might seem familiar because I was having trouble compiling classes and posted a thread that involves some of the same classes.

Basically, I have 3 classes: Item, Storefront, and GiftShop. Item and Storefront exist in a package called com.skyreign.store. GiftShop exists in a package called com.skyreign.shop.

Storefront uses Item. GiftShop uses Storefront and Item. I have successfully compiled all 3 files.

I can successfully run GiftShop by typing this into the command prompt:

Code:

---

C:\Programming\Java\bin>java com.skyreign.shop.GiftShop

---

However, if I move up a directory by typing this:

Code:

---

C:\Programming\Java\bin>cd ..\

---

And then try to run GiftShop again by typing this:

Code:

---

C:\Programming\Java>java bin\com.skyreign.shop.GiftShop

---

I receive this output:

Code:

---

Exception in thread "main" java.lang.NoClassDefFoundError: bin\com/skyreign/shop
/GiftShop (wrong name: com/skyreign/shop/GiftShop)
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(Unknown Source)
        at java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.defineClass(Unknown Source)
        at java.net.URLClassLoader.access$100(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

---

It seems that it successfully found the main class of GiftShop, which I think is good :(clap): But I don't understand what the exception is trying to tell me. I have searched around this forum for similar threads and I have deduced that it has something to do with my classpath being off.

I realize that I can run the class successfully, but I'm not satisfied because I want to know exactly what is going on. I think it's important to get a grasp of running and compiling files before I move on.

Any help would be appreciated.

The parameter to the java command is the full class name (including package).
Your class is not called 'bin\com.skyreign.shop.GiftShop'.

If you want to run it from another directory than the bin directory then you will need to provide a classpath that includes that bin directory, eg:
java -cp C:\Programming\Java\bin com.skyreign.shop.GiftShop
which will tell the JVM that it needs to look for the classes to run in the given directory.

Thank you so much! I just want to clarify something about the classpath, though.

When using the javac tool in order to compile a source file, I need to specify a classpath that contains the class files that are referenced in the source file that I am currently trying to compile.

Ex: Storefront references Item. Item.class is located in the bin folder. If I want to compile the Storefront source file, then typing this into the command prompt works:

Code:

---

C:\Programming\Java>javac -d bin -cp bin src\com\skyreign\store\Storefront.java

---

But if I want to run the Storefront.class file, I need to specify a classpath that contains Item.class again?

Java needs to know where the classes are.
It takes the value supplied to '-cp' first, if none is defined it then takes any CLASSPATH defined (note, don't define this in your environment variables, batch files is OK, but global is a Bad Thing), finally defaulting to '.'.
So yes, you'd need to tell it where the classes are if you plan on running anywhere other than that bin directory.

Okay, that makes sense. Any time a class is used, Java needs to know where it is located.

I'm just curious, though. What is wrong with defining a CLASSPATH as a global environment variable?

What if you had several Java applications, each needing their own classpath?

That would be inconvenient, then. Ok, thanks.

I've seen it happen in live deployment environments before, where someone clearly thought "we'll only ever need version X of these jars" and set up a server-wide classpath. And then another app gets deployed that needs a different version, and then another and another...how we laughed...