ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From v...@trilogy.com
Subject Re: newbie question: javac not checking build dependencies?
Date Thu, 03 Jan 2002 16:46:41 GMT
> Or you could look at the <depend> task - it works a treat for me!

Note the following from its doc:

"To determine the class dependencies, the depend task analyses the class 
files of all class files passed to it. Depend does not parse your source 
code in any way but relies upon the class references encoded into the 
class files by the compiler. This is generally faster than parsing the 
Java source."

Fair warning: as its documentations states this task gets its data from 
parsing .class files, not .java files. Some dependency information is lost 
this way, specifically static final fields that are initialized with 
compile-time constant expressions are in effect _statically_ "linked". I 
am sure this has been discussed many times here and elsewhere, so I won't 
bore you with an example. But if you accidentally use this incremental 
build mode to produce your final production build, you may end up with 
some incorrectly built classes. Ensuring that you always start with a 
clean state for the production build will prevent this, though.

Compare this to how the javamake tool handles this. It is very similar, 
but at least the important bit is documented explicitly. It handles static 
finals correctly, although the result is an overkill:

"Due to the above optimization in Java we, in general, are unable to deduce 
which classes reference a given non-private compile-time constant by 
analyzing class files only. [Vlad, staring here:] We could have done that 
by parsing source files, but this is a complex task, so instead we 
currently recompile all of the classes that may reference a given 
primitive constant, depending on its access modifiers. In the worst case, 
when such a field is public, the whole project will be recompiled. We 
recognize this problem, but hope that changes to primitive constants are 
unlikely to be frequent enough to make this a major inconvenience."

So, a public constant will cause a complete recompile. However, if you are 
smart and keep such constants in pseudo-interfaces used as "enumerations" 
[package-scoped if possible] and without anything else declared and thus 
rarely updated, this should not be a problem.

Ah, all in all there just isn't a perfect makedepends tool for Java...

Vlad.



Please respond to "Ant Users List" <ant-user@jakarta.apache.org>
To:     "Ant Users List" <ant-user@jakarta.apache.org>
cc: 

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


On Thursday 03 January 2002 15:38, you wrote:
<Snipped>
> Your choices are:
>
> - live with this javac limitation and always submit the full set of
> classes to be recompiled.
> - use a different compiler with built-in dependency analysis [jikes? The
> compiler in IBM's Eclipse is pretty smart, too.]
> - use some sort of a Java dependecy manager tool. They all differ in how
> smart they are. For some useful reading, check out this link [posted to
> this list a while ago]:
> http://www.experimentalstuff.com/Technologies/JavaMake/javamake.html

Or you could look at the <depend> task - it works a treat for me!

--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>





--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message