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 B.java 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. Vlad. 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" <[EMAIL PROTECTED]> To: Ant Users List <[EMAIL PROTECTED]> cc: Subject: Re: newbie question: javac not checking build dependencies? I have a question. Why use *.java or the depends task instead of using javac? The following excerpt from the Java2 SDK 1.3.1 explains what javac does. Isn't this the correct way to do dependency checking for Java? SEARCHING FOR TYPES When compiling a source file, the compiler often needs information about a type it does not yet recognize. The compiler needs type information for every class or interface used, extended, or implemented in the source file. This includes classes and interfaces not explicitly mentioned in the source file but which provide information through inheritance. For example, when you subclass java.applet.Applet, you are also using Applet's ancestor classes: java.awt.Panel, java.awt.Container, java.awt.Component, and java.awt.Object. When the compiler needs type information, it looks for a source file or class file which defines the type. The compiler searches first in the bootstrap and extension classes, then in the user class path. The user class path is defined by setting the CLASSPATH environment variable or by using the -classpath command line option. (For details, see Setting the Class Path). If you use the -sourcepath option, the compiler searches the indicated path for source files; otherwise the compiler searches the user class path both for class files and 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. Here is how javac handles each situation: Search produces a class file but no source file: javac uses the class file. Search produces a source file but no class file: javac compiles the source file and uses the resulting class file. Search produces both a source file and a class file: javac determines whether 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, javac just uses the class file. By default, javac considers a class file out of date only if it is older than the source file. (The -Xdepend option specifies a slower but more reliable procedure.) Note that javac can silently compile source files not mentioned on the command line. Use the -verbose option to trace automatic compilation. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
