ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: newbie question: javac not checking build dependencies?
Date Thu, 03 Jan 2002 23:22:16 GMT
 If class A uses a static final int constant "FIVE" from class B (let's say 
it evaluates to "5"), that constant is not embedded in A as a symbolic 
link to "B.FIVE". Instead, the _literal value_ 5 is emitted into the 
bytecode in A.class file. That's it, the dependency of A on B is _lost_ at 
that point. If javac locates A.class during any variation of the scheme 
that you refer to, it has no need to look further for or B.class, 
because A.class already contains everything it may need and no extra type 
information about field FIVE is required [in fact, javac can't even know 
there is such a field by looking at A.class only]. If B is later 
recompiled separately, A.class and B.class will be out of synch.

If <depend> does not handle static finals like the javamake tool, it can 
produce invalid builds in incremental mode. In all fairness, I have not 
gone through the sources to ascertain one way or another, but that's why I 
gave my warning earlier in the thread. javamake's solution is a bit of an 
overkill, but at least it's documented and is guaranteed to be correct.

The dependency of A on B through static final constants can only be 
resurrected by parsing the sources. This is a fundamental problem with 
Java itself and no "depends"-like tool will solve this problem correctly 
without using either the javamake approach or by parsing the sources. 
C/C++ has no issue here because #include's could be recovered from the 
sources very easily. But once you start parsing Java sources, you find 
that it's half of the job of compiling everything already, so you might 
instead just do that. 


P.S. Interestingly enough, by now Sun could have added a new attribute to 
.class format that could be used to simulate symbolic links for all static 
finals that got optimized into literals. Then we could have had a perfect 
depends tool...

Please respond to "Ant Users List" <>
To:     Ant Users List <>

Subject:        Re: newbie question: javac not checking build dependencies?

I have a question. Why use *.java or the depends task instead of using 
The following excerpt from the Java2 SDK 1.3.1 explains what javac does. 
this the correct way to do dependency checking for Java?

When compiling a source file, the compiler often needs information about a 
it does not yet recognize. The compiler needs type information for every 
or interface used, extended, or implemented in the source file. This 
classes and interfaces not explicitly mentioned in the source file but 
provide information through inheritance.
For example, when you subclass java.applet.Applet, you are also using 
ancestor classes: java.awt.Panel, java.awt.Container, java.awt.Component, 

When the compiler needs type information, it looks for a source file or 
file which defines the type. The compiler searches first in the bootstrap 
extension classes, then in the user class path. The user class path is 
by setting the CLASSPATH environment variable or by using the -classpath
command line option. (For details, see Setting the Class Path). If you use 
-sourcepath option, the compiler searches the indicated path for source 
otherwise the compiler searches the user class path both for class files 
source files. You can specify different bootstrap or extension classes 
with the
-bootclasspath and -extdirs options; see Cross-Compilation Options below.

A successful type search may produce a class file, a source file, or both. 
is how javac handles each situation:

Search produces a class file but no source file: javac uses the class 

Search produces a source file but no class file: javac compiles the source 
and uses the resulting class file.

Search produces both a source file and a class file: javac determines 
the class file is out of date. If the class file is out of date, javac
recompiles the source file and uses the updated class file. Otherwise, 
just uses the class file.
By default, javac considers a class file out of date only if it is older 
the source file. (The -Xdepend option specifies a slower but more reliable

Note that javac can silently compile source files not mentioned on the 
line. Use the -verbose option to trace automatic compilation.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message