RFR: 8364361: [process] java.lang.Process should implement Closeable [v14]

[Jason Mehrens]

On Sat, 4 Oct 2025 13:39:08 GMT, Alan Bateman <alanb at openjdk.org> 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