RFR: 8364361: [process] java.lang.Process should implement Closeable [v15]
Alan Bateman
alanb at openjdk.org
Fri Oct 17 11:31:06 UTC 2025
On Fri, 17 Oct 2025 01:36:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>>> @AlanBateman can you comment on the possibility of looping indefinitely and not be interruptible if the OS process cannot be destroyed.
>>
>> AutoCloseable and Closeable.close are specified to release the resources. If Process.close completes normally (no exception) then users should expect that all resources have been released and the process has terminated.
>>
>> In the current proposal, and assuming no interrupt, close waits indefinitely for the process to terminate. If close completes normally then you know the process has terminated. Someone might put code after the t-w-r to delete files or do other cleanup. It's similar to ExecutorService where close waits for all tasks to complete. So I think this part is okay.
>>
>> If interrupted while waiting then close should continue to wait or throw. I think the current proposal, to complete normally but leave the process behind, is problematic and surprising. Having close throw (probably IOException) is a bit problematic too as there isn't much you can do. We regularly see libraries ignoring the IOException thrown by close, including from writable streams where close is screaming that it was unable to flush buffered bytes. So while it wouldn't be terrible to throw, it may be better to keep close simple and be uninterruptible (meaning it would be complete normally when the process terminates and with the interrupt status set). Working through a few use-cases where you might use t-w-r with Process would help to validate the direction
>
> Yes, that works fine as long as the OS can eventually terminate the process.
> I was conerned that the OS may not be able to destroy the process without external intervention and the application would look like it is hung in `Process.close()`.
> I've seen a few zombie processes on Linux that `kill -9` can't get rid of. The advice in that case is to manually kill the parent of the hung process so `init` can take over as the parent and reap the process status.
> The recent commit implements the loop to wait forever for the process to terminate; that covers the cases that can be setup with testing.
Thanks for the update. I have sympathy for zombie scenario but it would be too surprising for close to completely normally in that case. So I think the updated proposal looks reasonable and we should see what we can do to improve diagnosability when blocked indefinitely in close.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2439476760
More information about the core-libs-dev
mailing list