I agree with Jonathan. For tests like my ancient MineField.sh it's hard for java code to beat the compactness of bash code for testing command execution, so I agree that shell execution should remain an option, while continuing to make it easier to write both shell and java tests that spawn subprocesses.
Some Google perspective: we also have bash libraries. They might get source'd multiple times, so should be idempotent (we actually use C style include guards in bash libraries). I used to believe that standalone execution of tests was a nice feature, but agree it's less of a concern now. It's very nice for jtreg to provide a -show:rerun feature. One reason for running the test outside of the test harness is to insert a wrapper around the test process, e.g. point LD_LIBRARY_PATH at a debugging malloc or run under "strace -c" to measure syscalls. So we have a --run_under=... flag that takes care of many use cases for standalone execution.
