I don't know of any use cases for the interrupt handling introduced by the patch currently. Restoring the interrupted status seemed more reasonable than swallowing them, as it gives the caller a chance to detect that the thread has been interrupted (i.e. Thread.interrupted or Thread.isInterrupted).
The patch raises an exception if the thread is interrupted while waiting for the spawned process to die. I'll do another pass and improve the error handling.
Off the top of my head, maybe the following:
o method sleep: ignore interrupt, allow premature wakeup, leave interrupted status cleared
o javaProcess.waitFor: throw exception, leave interrupted status cleared
o xSaver.join: not sure about this one. Would it be best to retry, or simply continue (as with current patch)?
As you say, I don't think the test framework will interrupt the thread in the normal case. The reason for not restoring the interrupted flag in the cases were we don't handle it must be that it can cause other code to fall over, i.e. IO calls in another unrelated test. The caller probably can't do anything to recover from the interrupts, so it would maybe be better to swallow them after all (except for in the javaProcess.waitFor case).