javac doesn't find my anonymous classes

[Ed Severn]

I'm sorry of this question has been posed and answered many times before.
But I have avoided using the "package" statement because of this.

Most of my classes have no "package" statement, and their class files are
stored in my current directory. Using "javac abc.java" works just fine.

But some of my classes *do* have "package" statements. I try to compile
them with "javac -d . def.java" so that the class file will be stored in a
directory structure.

But def.java refers to some anonymous classes whose class files are stored
in the current directory. The "javac -d . def.java" can't find these
classes. Why not?

My classpath is ".;c:\Sub\Java\JRE", which works fine for my anonymous
classes.

....Ed

[Raymond DeCampo]

Ed Severn wrote:

I'm sorry of this question has been posed and answered many times before.
But I have avoided using the "package" statement because of this.

Most of my classes have no "package" statement, and their class files are
stored in my current directory. Using "javac abc.java" works just fine.

But some of my classes *do* have "package" statements. I try to compile
them with "javac -d . def.java" so that the class file will be stored in a
directory structure.

But def.java refers to some anonymous classes whose class files are stored
in the current directory. The "javac -d . def.java" can't find these
classes. Why not?

My classpath is ".;c:\Sub\Java\JRE", which works fine for my anonymous
classes.

Ed,

Perhaps we have terminology issues, but I do not see how def.java could
refer to anonymous classes that it does not contain. If def.java
contains the anonymous classes, then the compiler does not need to find
them anywhere, it will create them. If it does not contain the
anonymous classes, then how can def.java refer to them? Anonymous
classes have no name and thus cannot be referenced.

Perhaps if you posted the smallest version of def.java you can create
that still exhibits the problem, I could be more helpful.

Ray

--
XML is the programmer's duct tape.

[Ed Severn]

Raymond,

Yes, I was sloppy there. I meant that "def.java" uses class "ghi", say, but
"ghi.java" does not have a "package" statement. So "ghi" belongs to the
"anonymous" package (which is probably the wrong term to use).

Perhaps the answer to my question is that when I compile def.java (which has
a "package p.q.r;" statement), then the compiler expects that "ghi" belongs
to that same package "p.q.r", and the compiler looks for "ghi.class" in the
p/q/r directory.

If this is the case, then how can "def.java" make use of a class (namely
"ghi") which does not belong to any named package?

....Ed

"Raymond DeCampo" <no****@twcny.rr.com> wrote in message
news:4K*****************@twister.nyroc.rr.com...

Ed Severn wrote:

I'm sorry of this question has been posed and answered many times before. But I have avoided using the "package" statement because of this.

Most of my classes have no "package" statement, and their class files are stored in my current directory. Using "javac abc.java" works just fine.

But some of my classes *do* have "package" statements. I try to compile
them with "javac -d . def.java" so that the class file will be stored in a directory structure.

But def.java refers to some anonymous classes whose class files are stored in the current directory. The "javac -d . def.java" can't find these
classes. Why not?

My classpath is ".;c:\Sub\Java\JRE", which works fine for my anonymous
classes.

Ed,

Perhaps we have terminology issues, but I do not see how def.java could
refer to anonymous classes that it does not contain. If def.java
contains the anonymous classes, then the compiler does not need to find
them anywhere, it will create them. If it does not contain the
anonymous classes, then how can def.java refer to them? Anonymous
classes have no name and thus cannot be referenced.

Perhaps if you posted the smallest version of def.java you can create
that still exhibits the problem, I could be more helpful.

Ray

--
XML is the programmer's duct tape.

[Raymond DeCampo]

Ed Severn wrote:

Raymond,

Yes, I was sloppy there. I meant that "def.java" uses class "ghi", say, but
"ghi.java" does not have a "package" statement. So "ghi" belongs to the
"anonymous" package (which is probably the wrong term to use).
I think the proper term is the "default" package.

Perhaps the answer to my question is that when I compile def.java (which has
a "package p.q.r;" statement), then the compiler expects that "ghi" belongs
to that same package "p.q.r", and the compiler looks for "ghi.class" in the
p/q/r directory.

If this is the case, then how can "def.java" make use of a class (namely
"ghi") which does not belong to any named package?

Well, you could be out of luck. I remember seeing a bug report on Sun
that seemed to be in this area; I think they made it so you can't import
a class from the default package (i.e., using an import directive).

Assuming that you are not out of luck, this is how I would approach the
problem. First, compile ghi.java to generate ghi.class and place it in
a directory called classes (for example). Make sure that the classes
directory is in the classpath when you compile def.java.

If this does not work, I would consider rewriting ghi.java so that it
belongs to a package and then can be imported in def.java. If you do
not have the source code for ghi.java, you might consider decompiling
it, assuming that the license under which you obtained it allows that,
or asking the library provider to provide a usable library.

(Another possibility is moving def.java into the default package, but
that is really moving in the wrong direction.)

HTH,
Ray

--
XML is the programmer's duct tape.