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

[David Holmes]

On Thu, 21 Aug 2025 02:48:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> That would be an incompatible change as subclasses could no longer define operations that are atomic with respect to the superclass methods that lock `this`.
>
> Maybe there is a cleaner overall solution that doesn't require locking `this` at all... ?
> 
> For example... just brainstorming, this is not fully baked and probably outside of the scope of this PR...
> * Use `AtomicReference.getAndUpdate()` to set `inputCharset`, `outputCharset`, and `errorCharset` and check for conflicting values
> * Use `StableValue` for creating `inputReader`, `outputWriter`, and `errorWriter` (using the chosen charset)
> * Make `closed` an `AtomicBoolean` and use `compareAndSwap()` to make `close()` idempotent
> * In `close()`, obtain `inputReader`, `outputWriter`, and `errorWriter` from their `StableValue`s and just forcibly close them. We may unnecessarily create a transient reader or writer(s) but so what.
> 
> I think it's worthwhile to minimize locking in `Process` because it's more likely than most classes to be accessed by multiple threads at once.

Removing the locking breaks compatibility in the same way. You can argue the use of `synchronized(this)` is not specified anywhere, but people can become aware of it and depend on it. The CSR request would have to determine whether this is acceptable or not.

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

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