RFR: 8364361: [process] java.lang.Process should implement close and be AutoCloseable

[Archie Cobbs]

On Tue, 5 Aug 2025 21:06:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Regardless of an interrupt, the process is destroyed, so there is no use to propagate the interrupt.
>> 
>> While it's true that it doesn't matter if the purpose of the interruption was only to interrupt the `close()` invocation, couldn't this `close()` operation be one of several different "shutdown" actions the thread is taking, some of which do throw `InterruptedException`, in which the purpose of the interruption is to interrupt any or all of them? In that case, you'd want the interrupt to "hang around" so it can happen if/when the next interruptible operation occurs.
>> 
>> In the example below, if the interruption just happens to occur during `Process.close()`, you want an `InterruptedException` to be thrown by `thing3.shutdown()` immediately (or as soon as possible):
>> 
>> try {
>>     thing1.shutdown();    // throws InterruptedException
>>     process2.close();     // does not throw InterruptedException
>>     thing3.shutdown();    // throws InterruptedException
>> } catch (InterruptedException e) {
>>    // bail out now
>> }
>
> I'm a bit dubious about the code above because it does not appear to fully handle the InterruptedException.
> If it is really shutting down then its just complicit in leaving the application is an unpredictable and probably unrecoverable state.
> 
> Propagating the checked exception reduces the usability of close() to the point that I would remove the waitFor.
> It annoying enough already that `waitFor` throws InterruptedException and you have to write more code and maybe a loop to handle that interruption and what it means to the caller.
> I would leave up to the caller to handle that case.
> When used with try-with-resources, the exception handling/re-throwing is complicated enough.

You make some good points. Still, I think swallowing `InterruptException`'s in library code is generally considered to be wrong. According to _Java Concurrency in Practice_  §7.1.3:

> If you don't want to or cannot propagate `InterruptedException`... you need to find another way to preserve the interruption request. The standard way to do this is to restore the interrupted status by calling interrupt again. What you should not do is swallow the `InterruptedException` by catching it and doing nothing in the catch block, unless your code is actually implementing the interruption policy for a thread.

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

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