Less IO for your Java Unit Tests

This is an awesome idea. Well, let me restate that: this is an awesome geek hack.

I posit that this kind of tomfoolery is required because (in my experience) profiling tools are (1) expensive (2) hard to use (3) inaccurate [could be due to #2] or the combination of the preceding.

Also, my current employer's tests run in the order of magnitude of hours, and I doubt very seriously that they are I/O bound (or network bound) in the manner that this page discusses. But, again falling back on the "hard to know without tooling", I couldn't state with any confidence exactly what the problem is with the tests, so this may be a great start toward finding out.

mdaniel: I've seen no profiling tools that can reliably perform this kind of automated profiling and force people to think about certain issues. You're spot on—the tooling is more about raising awareness than making your build faster, or slower. There are many legitimate reasons to have a very-slow build. It should be the choice of a fully-informed human to figure out the trade off and make a conscious decision.

our build is now using this, thank you. discovered some nasty io.