"Vitaly Stulsky" <[EMAIL PROTECTED]> wrote:
I found the similar library on: http://www.alphaworks.ibm.com/tech/jikesbt May be it will be interesting for you.
Alphaworks software is normally time-limited or evaluation only AFAIK.
> However, I am not sure but I think there are one or two ways that this
could
> theoretically slip up. If you use an optimising compiler on this, which is
> basically acting like an IFDEF in C:
>
> if (Constants.DEBUG) { logger.println ("working okay"); }
>
> and Constants.DEBUG happens to be false, the optimising compiler may (I
> think even javac does this normally) just not compile the whole line, and
> may not even put a reference in to the Constants class in the .class file
> header. Even worse, anything inside that block may not be referenced. But
> this is just speculation.
From my point of view we cannot rely on any speculation.
I'm not asking you to _rely_ on any speculation. I'm simply saying, _if_ now, or even in the future, any Java compiler strips out references to other class files in a class file, then dependency checking will not work correctly if it is only based on analysing dependencies in class files.
One compliler can
do things like that, other doesn't. I have one thought about this problem: If compiled .class file (1) doesn't use modified and recompiled other .class file(2) - .java file which corresponds to the .class file (1) hasn't to be recompiled. I think this assumption guarantee project integrity.
No it doesn't, if you have an optimising compiler. Re-read my explanations above and below.
> In any case, why should Ant place restrictions on what optimisations the
> compiler can do? Well, you could say "that should be the job of a separate
> optimiser/obfuscator", but perhaps there are some optimisations best done
in
> the compiler. I'm not an expert in this area.
I agree with you. It isn't job of make tool to put additional restrictions on the compiler.
> If you parse the .java files you are GUARANTEED to pick up all the
> dependencies, no matter what the compiler does. And since there is already
a
> public domain Java parser out there that comes with ANTLR, why not use it?
Yes, but parsing is too slow (1),
I disagree. I think the process will be disc-bound as I said above, so the speed of the filesystem interaction will be the key factor, not the speed of the parsing.
and parsing can find non-actual
dependencies(2).
Both true. But if you admit there are "non-actual" (you mean non-relevant) dependencies, then you must admit that there can be _relevant_ dependencies which are stripped out in the .class file!
Example: A.java contains
if (Constants.DEBUG) logger.println ("done it");Now if this line is optimised away by the compiler, and then only the file Constants.java is changed, you will not necessarily be able to tell from looking at A.class that A.java depends on Constants, because there might be no reference to Constants at all in A.class.
I'm ready to make any job and sacrifice my spare time for this work.
Glad to hear it! Ant is a really cool tool - we need some hot code-meisters to improve it even more!
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
