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

[Roger Riggs]

On Wed, 8 Oct 2025 14:04:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data.
>
> Looping could still lead to an infinite hang if the process never dies.
> For example, some Unix processes can stay around as zombie's even after kill -9 if they don't get reap'ed.
> On Windows, some files can't be closed and the processes hang around indefinitely.
> Tracking down those dependencies and resolving them is outside of the Java scope.
> I don't think the contract for T-W-R/close has guarantee the process has gone away, only that it has been destroyed (forcibly).

> I also wonder if close of streams should happen after first wait on destroy or on interruption. I'm thinking the difference is that streams would still be usable to fetch buffered data.

When close() is called, the application can no longer expect the streams to have any data; any buffered data is lost. (I'm assuming a single threaded application).  Asynchronous close() can result in races, but there's no good way (for the APIs/implementation) to get deterministic behavior. Shutting down the streams is the clearest and definitive way to bring things to an end.

If the application wants fine grained control of the timing of the closes, it is free to close them explicitly.
I would expect an application that is piping data to a process would close its output to the process and keep reading until EOF before exiting T-W-R or calling close.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2414243255