> <depend> really answers the question "What do I need to
> *recompile* due to a
> change in my source?" It does that by looking at the class
> file to see which
> other classes a class uses. ...
>
> In your case, you are interested in dependencies in the
> opposite direction -
> which classes do I need to exist in order to compile my
> class? Normally the
> Javac compiler will handle this issue....
Wasn't someone asking about cases that <depend> doesn't cover
(that is, the few kinds of source dependencies not reflected
in class files, or new source dependencies)?
Theoretically at least, might there be a place for a full source
dependency checker? It would do a full dependency check on the
current source (instead of looking at class files with: 1) not-quite-
full and 2) not-quite-current dependency information).
It could operate as <depend> does, deleting class files to force
the <javac> to recompile whatever needed to be recompiled.
<pie-in-the-sky probably-level="yeah, right">
Actually, wouldn't it be ideal if compilers wrote out dependency
information during regular compilation?
That is, every time the compiler compiled a Java source file, it would
write out an explicit list of the classes on which the newly-compiled
class depends.
Then:
- All dependencies would be captured (not just the 95% represented in
class files).
- Parsing and semantic analysis for dependency extraction wouldn't
take any extra time because it would use what the compiler has to
do anyway (and it wouldn't be a separate step).
(I worked on a compiler-like tool (for VHDL) that wrote out dependency
information like that for downstream tools to use.)
Of course, since class files contain most of the dependencies, too bad
they can't at least list the remaining dependencies for this purpose
(even if they shouldn't affect class-loading behavior).
</pie-in-the-sky>
Daniel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
