package import confusion

[Jt Walker]

I've been struggling with this for a day or two now and cannot seem to grasp what is going on.

The following code allows me to create a reference to the public class JOptionPane. As the wildcard import includes all the types in the package.the full class name is not needed.

// File : MessDialog.java

import javax.swing.*;

public class MessDialog {

	JOptionPane jop;
}

If I create a public class in a pkg :

// File : Qwerty.java

package pkg1;

public class Qwerty {

}

and then try to create a reference the compiler chokes :

// File : Asdf.java

import pkg1.*;

public class Asdf {
    Qwerty qwe;
}

Sample run :

scarlet@cloudbase:~/Java/WorkSpace$ echo $CLASSPATH

scarlet@cloudbase:~/Java/WorkSpace$ javac -version
javac 1.7.0_07
scarlet@cloudbase:~/Java/WorkSpace$ javac -d . MessDialog.java
scarlet@cloudbase:~/Java/WorkSpace$ javac -d . Qwerty.java 
scarlet@cloudbase:~/Java/WorkSpace$ javac -d . Asdf.java 
Asdf.java:6: error: cannot access Qwerty
    Qwerty qwe;
    ^
  bad source file: ./Qwerty.java
    file does not contain class Qwerty
    Please remove or make sure it appears in the correct subdirectory of the sourcepath.
scarlet@cloudbase:~/Java/WorkSpace$ 

I can't figure out why it fails and why is it referring to the source file ? The file pkg1/Qwerty.class exists. CLASSPATH is not set and so includes the current directory.

[Kemal Sokolovic]

Your package structure should be mapped to folder structure where your source files reside. Otherwise, you'll confuse javac.
But here I see you have all the source files in the same directory. Once you compile Qwerty.java, you should get subfolder named pkg1 in your current folder. Either move your Qwerty.java to that folder, or delete it after Qwerty.class is created in the subfolder, to avoid mentioned confusion.

Edit:
This is how it is supposed to look like:
.../Java/WorkSpace/src/MessDialog.java
.../Java/WorkSpace/src/Asdf.java
.../Java/WorkSpace/src/pkg1/Qwerty.java

and after you compile it, you should get something like this (suppose the bin is subfolder where you put you .class files):

.../Java/WorkSpace/bin/MessDialog.class
.../Java/WorkSpace/bin/Asdf.class
.../Java/WorkSpace/bin/pkg1/Qwerty.class

[Jeff Verdegan]

Jt Walker wrote:CLASSPATH is not set and so includes the current directory.

That's where the problem lies. You need to have classes in directories corresponding to their packages and include the parent directory of the package root in your classpath.

:; find ~/scratch/src ~/scratch/target/classes -type f
/home/jeff/scratch/src/main/java/com/xxx/tools/db/integrity/DatabaseMatcher.java
/home/jeff/scratch/target/classes/com/xxx/util/Util.class

My classes are

package com.xxx.tools.db.integrity;
//or
package com.xxx.util;

So to compile DatabaseMatcher.java, I'd do

:; cd ~/scratch/src
:; javac -cp ../target/classes com/xxx/tools/db/integrity/DatabaseMager.java

Note that you cannot "trade off" elements of your classpath by cd-ing deeper into its directory. The classpath element must include the parent directory of the package root.

[Jt Walker]

Thanks for the excellent help. I was led astray by SCJP 6 ( Raposa ) page 19 where it states

You might have also noticed that the source code files in \src use the same directory
structure as their package names. This is not a requirement for your .java files; they can
be stored in any directory.

Moved the source to pkg1/Qwerty.java and everything is peachy.

[Jeff Verdegan]

Jt Walker wrote:
Thanks for the excellent help. I was led astray by SCJP 6 ( Raposa ) page 19 where it states

You might have also noticed that the source code files in \src use the same directory
structure as their package names. This is not a requirement for your .java files; they can
be stored in any directory.

Moved the source to pkg1/Qwerty.java and everything is peachy.

Yeah, that comment, while correct, can lead to confusion.

The Java compiler spec does not require that .java files be in a directory that matches their package. A given implementation of the compiler might require it though. And it's a good idea to do it that way regardless, to avoid confusion.

Additionally, the standard classloader mechanism does require that a class's package name corresponds to its subdirectory relative to a classpath root.

So even though it's not strictly required in all situations, it's best just to act as if it is.

[Kemal Sokolovic]

Jt Walker wrote:
Thanks for the excellent help. ...

Any time, and welcome to the Ranch!