On Thu, 21 Aug 2025 13:17:55 GMT, Roger Riggs <[email protected]> wrote:
>> What David said is right although it doesn't really make sense to extend >> Process, at least not outside the JDK. If the API were introduced today then >> it wouldn't have a public constructor, or maybe it would be a sealed >> hierarchy. It's possible of course that that there are Process >> implementations for testing or delegation but unlikely a "real >> implementation". > > Its easy enough to use an atomic update to achieve the idempotent behavior. > But two racing threads calling close raise the question of the state after > close returns. > To assert that the process has been "closed" then both threads have to wait > until its finished. > The normal developer would expect that close is complete after return; so > somebody has to wait. A corpus search found a few overrides of Process. Some have overridden the `close` method to destroy the process, either by calling Process.destroy or directly using OS specific APIs. None of the `close` methods throw IOException, so not causing a source compatibility issue. None of them close the streams. The subclasses appear to help keep track of Processes or enhance communications over the standard streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26649#discussion_r2319496727
