ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Couple of mods to <javac>
Date Mon, 11 Sep 2000 09:23:24 GMT

I'm -1 on your patch and I hope I can explain why. The assumption that the
source tree is structured according to the package structure is not unique
to ant but is also used by the Sun javac compiler and, I presume, all other
Java compilers. When a class depends on another class, for which no class
file exists, Javac can automatically compiler a source file to produce a
class file to satisfy the dependency. It can only do so however, if the
classes and source exist in a directory structure which matches the package

I have attached an example consisting of two classes in two packages, one of
which is dependent on the other.

If you try to compile just the class you get the following

F:\example>javac y\
y\ cannot resolve symbol
symbol  : class A
location: package x
import x.A;
y\ cannot resolve symbol
symbol  : class A
location: class y.B
    private A a;
2 errors

Javac cannot satify the class dependencies. If you now try

F:\example>javac -sourcepath . y\

You will find that it compiles and that javac has automatically built
x/A.class from x/ without you even asking it to do that. It only could
do that because the source files directory structure matches the package

So, there are certain benefits to arranging your source in this way. I think
a lot of people don't do this and end up with a flat set of Java source
files or files organized according in some other way. In most cases that
will still work, especially if you compile everyting the way ant will. For
example, the following compiles fine

F:\example>javac y\ x\

I think the current ant behaviour encourages you to use this layout and,
IMHO, that is a good thing. To allow it to support a flat or unrelated
directory structure would not be a good thing.

> One problem I was having with <javac> is that I have source files that
> live in subdirs, but that need to be built into the top level of the build
> tree.

I have to wonder why that is. At work, we have a number of source trees,
which are subdirectories of a "src" directory. These trees are each
organized along package structure lines and are built with independent
<javac> tasks.

> The problem was they were always getting rebuilt, since <javac>
> makes the class filename match the path of the source filename, and looks
> for destdir/srcpath/to/file.class rather than just destdir/file.class --
> which is perfectly fine in most cases, just not in all.

I feel it should be perfectly fine in all cases. Of course, that is easy to
say without knowing the details of your situation.

For further info on javac's behaviour, have a read of

under the section "SEARCHING FOR TYPES"


View raw message