On Tue, 5 Aug 2025 18:37:42 GMT, Rob Spoor <d...@openjdk.org> wrote:
>> The teardown of a Process launched by `ProcessBuilder` includes the closing
>> of streams and ensuring the termination of the process is the responsibility
>> of the caller. The `Process.close()` method provides a clear and obvious way
>> to ensure all the streams are closed and the process terminated.
>>
>> The try-with-resources statement is frequently used to open streams and
>> ensure they are closed on exiting the block. By implementing
>> `AutoClosable.close()` the completeness of closing the streams and process
>> termination can be done by try-with-resources.
>>
>> The actions of the `close()` method are to close each stream and destroy the
>> process if it has not terminated.
>
> src/java.base/share/classes/java/lang/Process.java line 673:
>
>> 671: }
>> 672: } catch (InterruptedException ie) {
>> 673: // Wait was interrupted; terminate the process
>
> Shouldn't the thread's interrupted flag be restored?
Regardless of an interrupt, the process is destroyed, so there is no use to
propagate the interrupt.
It is debatable, whether or not and for how long to give the process time to
exit on its own.
If the process has any of its state (files or sockets, etc.) to cleanup,
destroying it might leave it in an unexpected state. All of the file
descriptors/handles will be closed by the OS, but files might have been
created. A robustly written application would/should be coded to deal with that
inconsistent persistent state.
The Java process invoking the child can use `waitFor` get the exit status and
wait for exit; generally it should not need to know anything about the child
process.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2255216685
