ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <hol...@yahoo.com>
Subject RE: Couple of mods to <javac>
Date Tue, 12 Sep 2000 00:06:11 GMT
Hi Conor,

What you say is true. And the compilers do do the right thing for these
files -- they put them in the directory specified by the -d option. I'm
not later moving them into the top-level -- that's where they get compiled
into, because these files aren't part of any package. But <javac>, as it
stands now, makes an assumption that all files are, and modifies the
classfile location accordingly, to do the existence/timestamp check.
That's fine for files that do belong to a package (and the ones I have
that do, live in the source tree in the subdirs appropriate to their
package), but it doesn't work for files that aren't part of a package.
Those files should be able to live in the source tree wherever it makes
sense for them to, since the compilers don't require they live any
particular place -- but currently, <javac> does.

Since the behaviour I added is only turned on when the "flatten" attribute
is set to true, it's something you'd have to specifically ask for in order
to get. So presumably, people would only ever do that when it was the
right thing to do.

On the subject of the other change I made: Did you have any feelings about
the "listfiles" stuff? It's also behaviour you'd specifically have to ask
for, so it seems pretty safe to include. As I said before, it's not
something I'd want to have turned on all the time, but it is something I'd
want to be able to, from time to time.

Thanks,
Diane

--- Conor MacNeill <conor@m64.com> wrote:
> Diane,
> 
> 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
> structure.
> 
> 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 B.java you get the following
> 
> F:\example>javac y\B.java
> y\B.java:3: cannot resolve symbol
> symbol  : class A
> location: package x
> import x.A;
>          ^
> y\B.java:6: 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\B.java
> 
> You will find that it compiles and that javac has automatically built
> x/A.class from x/A.java without you even asking it to do that. It only
> could
> do that because the source files directory structure matches the package
> structure.
> 
> 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\B.java x\A.java
> 
> 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
> http://java.sun.com/products/jdk/1.2/docs/tooldocs/win32/javac.html
> 
> under the section "SEARCHING FOR TYPES"
> 
> Cheers
> Conor
> 

> ATTACHMENT part 2 application/x-gzip name=example.zip



=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

Mime
View raw message