ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank E. Weiss" <>
Subject Re: newbie question: javac not checking build dependencies?
Date Fri, 04 Jan 2002 03:05:38 GMT
Thanks, Vlad, for taking the time to describe the problem in detail. I tried it
out and you are correct. I even tried oldjavac -Xdepend, which was fruitless.

I still have some questions before I can say I'm satisfied completely.

1) Is it only the static final constants that have this discontinuity in
javac's dependency checking? Usually such constants are used as manifest
constants, in the old K&R C language sense, and rarely are changed.
2) I couldn't find any documentation to support that this is possibly a
language issue, that it is consistent with the language definition. Anybody
3) Would it be a good guess that Sun has given up on real dependency checking
in the javac compiler? I notice that  -Xdepend is dropped from the 1.3.1
compiler. wrote:

>  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.
> 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...

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

View raw message