On Sat, 4 Oct 2025 13:39:08 GMT, Alan Bateman <[email protected]> wrote:
>>>... It puts doubt into the reader's mind that the process may not have >>>terminated and call waitFor after close to be sure. >> >> Process::isAlive may be true or false after Process::destroy. The API docs >> shouldn't forbid nor require a call to waitFor after close/destroy. If >> process is holding a lock on input file (Windows) and that caller want to >> delete after exit, the caller waitFor after close/destroy before calling >> File::delete. Destroy/close not waiting on exit is correct behavior. > >> Destroy/close not waiting on exit is correct behavior. > > Yes, for destroy (and clearly documented in the case destroyForcibly). It's > surprising and problematic for close. It creates a usability issue when using > try-with-resources as the resource (the Process in this case) is not in scope > after the t-w-r statement. Understood. Is the implication that close should waitFor exit? That gets tricky with forever wait, timeout, or if should escalate to destroyForcibly. With regards to scope, I would have to nest try blocks which is far from ideal. If there is no preference on when streams must be closed it is a bit cleaner nesting. If I step back, the pain point with process was closing three streams which may never be accessed other than close call. In t-w-r generates a compiler warning about the local var if I recall correctly. For fire and forget processes, I don't want close call destroy. At a minimum close should close the streams. The only other thing would be to add a method to ProcessBuilder that holds close Consumer<Process> to set behavior on close, but I haven't thought that through. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2404103980
