File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes help understanding the package declaration... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "help understanding the package declaration..." Watch "help understanding the package declaration..." New topic
Author

help understanding the package declaration...

Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
I'm running into some confusion regarding declaring packages. I'm studying for the SCJP, but this is probably a better forum to post too.
I use packages everyday at work building FormHandlers for ATG, but I blindly take things for granted, something you can't do on the SCJP. Help with what is going on the background is appreciated...
Given (in UNIX notation ):
set CLASSPATH = .:/java/src
The following directories and files:
/java/src/one
/java/src/two

At the command line (note the current directory ):
/java/src/two % javac Sub.java
Sub.java:3: Package one not found in import.
import one.*;
^
Sub.java:5: Superclass two.Super of class two.Sub not found.
public class Sub extends Super {
^
2 errors
BUT from the command line (again note the current directory):
/java/src % javac two/Sub.java
/java/src %
This compiles just fine! Can someone explain what is going on here? Is it my class path? Is it how I'm declaring the packages? Why can't I be in the directory of the subclass and compile?
Thanks. This is a confusing issue for me.
Tim

Timothy Stone, MIT, SCJP
http://www.petmystone.com/
"This Satan's drink [coffee] is so delicious, we shall cheat Satan and baptize it." --Pope Clement the VIII (1592-1605)
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
You tried to execute your application while sitting in one of the "packages". This might work, unless, as you did, you include the dot notation to include the "current directory" as part of the classpath. As a result the system is looking in
/java/src/two
to find the 2 packages. It can find two because that is "current" but it can not find a directory
/java/src/two/one
Now if you execute from the directory /java/src/ or for that matter anywhere else on the system, all should be well because it will find both "packages" under the current directory or the classpath.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
Originally posted by Cindy Glass:
Now if you execute from the directory /java/src/ or for that matter anywhere else on the system, all should be well because it will find both "packages" under the current directory or the classpath.

Okay... then why this:
/ % java two.Sub
Exception in thread "main" java.lang.NoClassDefFoundError: two/Sub
/ % cd java
/java % java two.Sub
Exception in thread "main" java.lang.NoClassDefFoundError: two/Sub
/java % cd src
/java/src % java two.Sub
Variable x is: 10
/java/src %
I understood that I should be able to call this from anywhere on the system as long as I have my classpath set. But this appears to be a misunderstanding on my part.
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
There is no syntax that allows you to use a dot in the call to the program. You are only allowed to use
>java sub
Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
Originally posted by Cindy Glass:
There is no syntax that allows you to use a dot in the call to the program. You are only allowed to use
>java sub

See... I thought that you had to call the program with the dot syntax when defined in a package... this is specifically noted in the SCJP study guide.
[/java/src] % java Sub
Exception in thread "main" java.lang.NoClassDefFoundError: Sub
[/java/src] % java two.Sub
Variable x is: 10
[/java/src] %
[/java/src] % cd two
[/java/src/two] % java Sub
Exception in thread "main" java.lang.NoClassDefFoundError: Sub (wrong name: two/Sub)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:477)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:101)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:247)
at java.net.URLClassLoader.access$1(URLClassLoader.java:213)
at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:290)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
[/java/src/two] %
[This message has been edited by Timothy Stone (edited October 05, 2001).]
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
OK - I stand corrected. You can use the dot syntax, WE just never do in our environment. Give me a second to re-read your posts.
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
I still think, as I said above, that the problem in the dot in your classpath. If you are sitting in the sub-directory, the system now has a choice of two places to start from. The current directory
/java/src/two
or the directory named in your classpath
/java/src/
It chooses the current directory over the other one. Therefore it is looking BELOW the /two (which it now thinks is the main classpath) directory for the other directories and can't find them.
Nain Hwu
Ranch Hand

Joined: Sep 16, 2001
Posts: 139
Timothy,
I don't think you should have problem to compile and run
the code as you described. So, I decided to try it myself.
Sure enough, I have NO problem to compile and run the
code according to your settings and your procedure.
I am running JDK1.3.1 in windows 95 environment (sorry I don't
have unix env)
My understanding is that as long as you have CLASSPATH
setup right (notice this is not recommended way. According to
JDK, the preferred way is to use command option -classpath),
you can compile from where the source file is located.
Then, you can run the code anywhere you like, as long as you
specify the "full name" (including package name) of the class,
such as two.Sub as you have tried.
Sorry, I can't explain why it doesn't work for you.
Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
Nain,
Can you show me your classpath?
I'm also running a WinNT box, but both my UNIX and NT JVMs are 1.2.2.
Thanks.
Nain Hwu
Ranch Hand

Joined: Sep 16, 2001
Posts: 139
Here is my env. I created subdirectories under D:\pfe101i.
Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
So... you can compile Sub.java from C:\pfe101i\java\src\two ?
For me this works...
[/java/src/two] % javac -classpath ../ Sub.java
[/java/src/two] %
But this does not...
[/java/src/two] % javac Sub.java
Sub.java:3: Package one not found in import.
import one.*;
^
Sub.java:5: Superclass two.Super of class two.Sub not found.
public class Sub extends Super {
^
2 errors
[/java/src/two] %
My classpath...
[/java/src/two] % echo $CLASSPATH
[/java/src/two] % .:/usr/java1.2/bin:/java/src

[This message has been edited by Timothy Stone (edited October 05, 2001).]
Nain Hwu
Ranch Hand

Joined: Sep 16, 2001
Posts: 139

So... you can compile Sub.java from C:\pfe101i\java\src\two ?

I can compile Sub.java from D:\pfe101i\java\src\two, where the
source file Sub.java is located.
I retried by using -classpath option and it worked the same.
After compilation, I got following .class files:
D:\pfe101i\java\src\one\Super.class
D:\pfe101i\java\src\two\Sub.class
Then, I went to root (D:\) and issue the command:
java -classpath D:\pfe101i\java\src two.Sub
I got the output:
Variable x is: 10
Looks like it is something wrong with JDK1.2???
Timothy Stone
Ranch Hand

Joined: Aug 01, 2001
Posts: 71
Cindy, Nain, et. al...
Well, I think I had a good understanding of the package declaration until yesterday when I stumbled across my troubles. Nain, you may have stumbled across the answer, but I don't want to say it's true... it could be a problem with v1.2.2. I'm more inclined to believe it to be a problem with my environment at work.
I went home, set up the same classpath and directories... and it compiled fine from the "current directory." Just as Nain is experiencing in his final post. I'm running as follows:
[~...java/com/petmystone] Ready: java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root-010902-18:51)
Java HotSpot(TM) Client VM (build 1.3.1, mixed mode)
[~...java/com/petmystone] Ready:
This is on the Mac OS X (10.1) as well.
It could be something with the environment at work. NT. Solaris. I don't know!
Having it work as intended at home has helped me clear my mind of the confusion. If anyone reading this thread has ideas that may be causing the problem as chronicled here, please post.
Thanks for all the help and suggestions.
Tim
Nain Hwu
Ranch Hand

Joined: Sep 16, 2001
Posts: 139
Tim,
I don't have any problem in my env. What I said in my
last post is that it worked both ways - either using
CLASSPATH or "-o classpath" option.
Anyway, glad to see you are clear about the whole idea
of packaging in java.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: help understanding the package declaration...