ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <>
Subject Re: Smarter Javac
Date Sat, 17 Nov 2001 09:00:48 GMT
This would IMHO be a very valuable addition.  

One thing to think about is that this type of facility is going to be 
generally useful for all
sorts of tasks.   For example, I coded up a similar gizmo for running 
XSLT transformers
to create HTML files from XML sources.  The transformers were 
parameterized with
all sorts of variables that came from multiple property files 
(company-wide defaults,
project-wide defaults, and so on).   If any of these parameters changed, 
I needed
to re-run the transformation even though _none_ of the XML source files 
had actually been

What I did was: I created a custom ant task that consolidated all of the 
multi-level properties into a single
consolidated "properties" object in memory.  It then prepared to write 
the consolidated properties file to disk,
but first checked to see if there was already a file of the same name. 
 If so, it computed the
checksum of the existing file against the checksum of the in-memory 
If the checksums matched, the ant task did NOT write out the 
consolidated file, and simply terminated.

Finally, I used the <dependset> task to force XSLT transformation to 
happen if the "consolidated properties"
file had changed.

I think what we may have here is an opportunity, over the fullness of 
time, to factor out all sorts
of generally useful functionality:

1) creation of property files from various sources (command options, etc.)
2) checksum computation
3) forcing a task to re-run itself based on the result of some checksum 

....or something like that...

Does this make sense?


Magesh Umasankar wrote:

>I noticed that this has been discussed for a short while
>a long time back, but nothing solidified though.  So,
>here goes:
>Javac, as we are all aware, determines the file set that
>is to be compiled based solely on comparing the
>timestamps of the source and destinaiton files.  However,
>this has got its limitations in numerous ways - one is
>dependency checking, which has been solved by the
>Depend task.  But still the glaring problem is this:
>Say I compile a bunch of files using debug mode and
>in my next iteration, I build it in non-debug mode, 
>without having changed any of my source files. Javac is 
>not going to catch this and would ignore processing any 
>files (Yes, I am coming from the CONS world ;-) )  This
>problem is going to exist when I switch compilers, or
>when I enable/diable warnings, etc.
>CONS has a nice way of solving this - it caches the 
>command line being used and checks against the cached one
>during future compiles to see if the current command line
>matches the earlier one.
>In the context of Ant, here is what I propose:
>A cache file would be maintained that holds key-value
>pairs.  A key-value pair is the task name and the MD5
>checksum of the Javac command line.  When a Javac task 
>named foo is invoked, the MD5 checksum of its command 
>line is computed and checked against the cache, if 
>available, by looking up the key foo.  If the cache isn't
>there, one is created.  If the checksums differ, all 
>source files would be compiled again and the new 
>checksum would be cached - otherwise, Javac would do 
>what it does now.
>While this may slow the Javac process launch just a 
>wee little bit, it would be of great use to the user.
>What do you think?  The crude proof-of-concept that I 
>built didn't change a lot of code at all...

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message