I think we'll al be disappointed if we implement this. The compilers and
the compiler spec itself change. They may get even "smarter" in terms of
dependencies and render any intelligence in Ant void or, even worse, a
hindrance. Any changes we make should follow closely with the intentions of
Sun and their specifications for the compiler. We run into the same issues
with where optimization is located. The concepts of object oriented
compilation, how byte code is handled and deployment will, for the near
future, be of some contention as the "kinks are worked out". What if javac
suddenly wants to compile straight to a WAR or JAR? How would dependencies
be handled outside of the compiler?
Anyway, just brining up points as to why this is a very difficult design decision.
Having ant be able to generate persistent dependency information might be a good compromise here. I wouldn't mind saying "ant depend" which would do a thorough dependency analysis looking at sub/super class relationships, and constant pool references. Preferably, an external XML file would be generated that would capture the current static dependency graph between class files. This file would act as a dependency cache, and would be quite fast to process. Perhaps this graph could even be updated incrementally whenever classes are recompiled.
A more sophisticated analsys would look at the constant pool references, and after having recompiled class A, upon which class B depends, a comparison of all of the constant pool method/field references would see if a recompile is necessary.
CodeWarrior's Java compiler seems to do some degree of this, as when I change certain .java files, other ones get recompiled.
- Patrick --
// Patrick C. Beard // Java Runtime Enthusiast -- "Will invoke interfaces for food." // mailto:[EMAIL PROTECTED]
