RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable [v2]
Roger Riggs
rriggs at openjdk.org
Fri Aug 8 17:40:12 UTC 2025
On Fri, 8 Aug 2025 15:52:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/Process.java line 655:
>>
>>> 653: quietClose(outputWriter != null ? outputWriter : getOutputStream());
>>> 654: quietClose(inputReader != null ? inputReader : getInputStream());
>>> 655: quietClose(errorReader != null ? errorReader : getErrorStream());
>>
>> Async close of process stream is a complicated here. Do you have a summary on how it behaves on both Unix and Windows? I'm thinking about the deferred close code in particular. (I don't have an issue with close throwing away the exceptions, I'm just not 100% sure that async close is reliable in the first place).
>>
>>> Closing an already closed stream usually has no effect but is specific to the stream.
>>
>> I wonder if we could specify Process::close to be idempotent. That would mean we couldn't attempt to re-close if a first close of stream failed or had some other side effect.
>
> That would remove any question about behavior without having to delve into the details of every stream close.
> Down at the bottom of every process stream is a FileDescriptor holding either an fd (Linux) or a handle (Windows).
> This is true for all the redirects whether to files, pipes, or inherited (stdin, stdout, stderr). The FileDescritor.close method is very careful to impotently close and reset the fd/handle.
I will note that when used in try-with-resources, making Process::close idempotent will not keep the streams from being closed twice.
T-W-R will close the streams as declared thru T-W-R variables, delegating the close() down through the streams to the Process streams. Later, Process::close will close the underlying writers or streams, in some cases for the second time.
The only place where idempotent will come into play is when called directly and then possibly later by T-W-R.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2263655091
More information about the core-libs-dev
mailing list