ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <gree...@hotmail.com>
Subject Re: How to participate?
Date Mon, 17 Apr 2000 20:23:22 GMT
"Vitaly Stulsky" <vitaly_stulsky@yahoo.com> 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


Mime
View raw message