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 Sat, 15 Apr 2000 13:28:32 GMT
"Vitaly Stulsky" <vitaly_stulsky@yahoo.com> wrote:

>From my side I want to ask one question: Is there any code standarts for
>this project?

I can answer this one: Yes.

http://jakarta.apache.org/guidelines/source.html

>I think it is possible to extend ANT to perform the dependence tracking 
>like
>JIKES do.

The easy part would be parsing the code (perhaps using an open source parser 
like ANTLR's Java one - no need to reinvent the wheel!). The part requiring 
a bit more thought would be to optimise the dependency tracking process - 
make reading back and regenerating the dependencies as fast as possible, 
bearing in mind that this task will (in my estimation, based on experience 
with javac -verbose) be filesystem-bound (held back by the speed of the 
filesystem rather than the processor). So you need to minimise filesystem 
read/writes. Unless we want to go down the road of "no permanent Ant working 
files should be created". -1 for that.

Of course, almost any kind of dependency tracking, however inefficient, is 
probably quicker than "build clean; build all" for non-trivial projects, but 
why not get it right the first time?

Someone previously suggested dependency checking based on .class files 
rather than .java files. True, there is already a lot of code available for 
parsing .class files:

http://dmoz.org/Computers/Programming/Languages/Java/Open_Source/Libraries/Data_Formats/Java_Class_Files/

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.

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.

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?

>Do you have any proposals for this and how do you see the future of ANT
>accroding this
>direction?
>

Unfortunately I have seen a lot of good ideas on this list and sometimes 
there is just no response at all from the committers! It's like, hello, 
what's going on! However, it's not like nothing is happening - there is a 
plan for the next release of Ant which can be found in the elzm archives.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Mime
View raw message