This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: Using AspectJ to Instrument the AspectJ Compiler
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
Problem: AspectJ incremental compiler requires manual intervention to do a compile. It acts like a daemon and tracks its state in memory. It supports stdin recompile commands or watching the timestamp on a flag file.
The real problem is that we want to be able to do a fast recompile (incremental) from an IDE so we can run unit tests frequently. This is more or less incompatible with how incremental works in iajc.
Solution 1: Use ruby's popen to handle the "press enter to recompile" type interactive compile. Have the script open a socket and listen for connections on some random high port. When a connection is established recompile and flag the client when it is finished.
However, java and ruby don't get along -- java sends an EOF instead of blocking to ruby's gets when there is no input to read, ruby sees the EOF and closes the IO instance =(
Solution 2: Modify the aspectj compiler to signal its state somehow. The aspectj compiler code is... interesting (in the art critic sense). You don't see named continues very often in Java for a reason. Maybe they like them at PARC, who knows.
Solution 2.1: Use aspectj to instrument the aspectj compiler to provide event callback hooks on the incremental compiler. Bingo!
This was actually really fun, but it means our build system uses a custom aspectjtools.jar. That said, recompiles are down to hundreds of milliseconds from a couple minutes. Basically I just added advice to the incremental looper to invoke named (properties file) java.lang.Runnable impls at the interesting bits in the compiler lifecycle. The basic socket solution from the ruby script can now be done in Groovy via callbacks instead of listening on a popen and the world is once again at peace.
Previous Topic
