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 Problems with import/package statements Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Problems with import/package statements" Watch "Problems with import/package statements" New topic
Author

Problems with import/package statements

Tim Oister
Greenhorn

Joined: Jan 23, 2003
Posts: 11
This is my second foray into the world of Java, and once again I'm hung up on trying to import packages. I understand the link between the directory structures and the naming of the packages, but when I actually try to implement even the simplest package/import functionality, I run into all sorts of problems. I've read almost every post on this topic (somewhere around a billion), but nothing directly addresses what I'm trying to do or explains it in easy-to-understand terms.
To make this easy to follow, I've created a directory called C:\Temp\Java. Off of this directory, I have a \source directory to hold all of the .java files, and a \classes directory to hold all of the compiled .class files. I'd like to keep the source code separated from the class files, because it keeps the directories at a manageable size.
I've created the following two program files (which don't do very much):
// PkgClass.java
package classes.packages;
public class PkgClass {
public PkgClass() {
System.out.println("New PkgClass created...");
}
public static void main(String[] args) {
System.out.println("PkgClass started...");
}
}
// CallPackage.java
import packages.PkgClass;
public class CallPackage {
public static void main(String[] args) {
System.out.println("Calling package...");
PkgClass pc = new PkgClass();
}
}
My CLASSPATH variable is:
CLASSPATH=.;<a bunch of Oracle .jar files>
I start by issuing the command:
C:\Temp\Java\source>javac -d .. PkgClass.java
This puts the PkgClass file in the C:\Temp\Java\classes\packages directory as expected. Now I want to compile the CallPackage.java file so that it ends up in the C:\Temp\Java\classes directory, so I issue the following command:
C:\Temp\Java\source>javac -d ..\classes -classpath ..\classes CallPackage
This gives the following error messages:
CallPackage.java:3: cannot access packages.PkgClass
bad class file: ..\classes\packages\PkgClass.class
class file contains wrong class: classes.packages.PkgClass
Please remove or make sure it appears in the correct subdirectory of the classpath.
import packages.PkgClass;
^
1 error
Is what I'm attempting to do possible (separate the source files from the compiled files)? If so, could anyone explain what I'd need to do with my simple classes above to get them into the proper directories and then explain how I execute the CallPackage program from the command line (which is another problem that I keep running into with package/import statements)?
Any help would be greatly appreciated!
Rodney Woodruff
Ranch Hand

Joined: Dec 04, 2001
Posts: 80
Hello,
First things first. You need to come up with a directory structure that works for you. In order to make sure that this works you should create a directory structure that is the reverse of your domain name.
For example:
Domain Name: yourdomain.com
Package Name: com.yourdomain
Source directory: C:\Temp\Java\source\com\yourdomain
Classes Directory: C:\Temp\Java\classes\com\yourdomain
or:
Domain Name: yourdomain.org
Package Name: org.yourdomain
Source directory: C:\Temp\Java\source\org\yourdomain
Classes Directory: C:\Temp\Java\classes\org\yourdomain
Now rewrite your classes as follows:


If you are in the source directory then your command line would look something like this:
javac -d ..\classes -classpath "." com\yourdomain\*.java
When the only item to be added to the classpath is the current directory, the dot is implicit. I added it hear for clarity's sake.
If you are in the com\yourdomain directory then adjust command line arguments accordingly:
javac -d C:\Temp\Java\classes -classpath ".;C:\Temp\Java\source" *.java
You can create any type of package hierarchy you like. The com.yourdomain tactic is the most commonly used.
[ March 03, 2003: Message edited by: Rodney Woodruff ]

Hope This Helps
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60991
    
  65


// PkgClass.java
package classes.packages;
// CallPackage.java
import packages.PkgClass;

These two statements don't jive. Is your package hierarchy rooted at classes or at packages? Pick one, but not both.
Given your setup, here's what I'd suggest:
Root your hierachy at classes by:
Adding the classes folder to you classpath, not ".".
On compile: "-D ../classes"
Imports: "import packages.Whatever;"
This should get you a lot closer.
hth,
bear


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60991
    
  65

And Rodney's point about picking a "real" name for you packages is a good one.
hth,
bear
Tim Oister
Greenhorn

Joined: Jan 23, 2003
Posts: 11
Thanks for the help! I modified my sample code and it worked great! Now that I have something that works, I can take a step back and see where I was going wrong.
Part of the problem was not going with the reverse-domain name for everything, even my little test snippets.
Thanks again!
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
One thing that is perhaps not yet clear:
Packages are not imported. Classes are imported.
import somePackage.SomeClass instructs the compiler that in order to compile this class, use of somePackage.SomeClass might be required.
import somePackage.* instructs the compiler that in order to compile this class, use of any of the classes in somePackage might be required.


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Problems with import/package statements