On Wed, 22 Oct 2025 18:26:16 GMT, Brian Burkhalter <[email protected]> wrote:

> Remove catching `InterruptedIOException` and throw `IOException` in response 
> to `InterruptedException` instead of throwing `InterruptedIOException`.

The hugely problematic and legacy interruptible I/O (Solaris mostly) was 
disabled in JDK 7 and the code removed in JDK 9. This means that I/O and 
network APIs that threw InterruptedIOException on Solaris in early JDK releases 
no longer throw this exception.

InterruptedIOException, with its bytesTransferred field, is also problematic, 
and long overdue deprecation. To some extend it is similar to ThreadDeath 
hanging around long after removing Therad.stop. It will take many releases and 
years before it can be a candidate to remove but we can at least start by 
deprecating it for removal to discourage usage.

For java.io, the last reference to InterruptedIOException was removed from the 
API docs in JDK 19 (JDK-8254574). Going further means removing undocumented 
behavior from the implementation. It means asking the question if there are 3rd 
party input/output streams throwing InterruptedIOException that are wrapped in 
a PrintStream or PrintWriter and that somehow user code is depending on this 
exception setting the interrupt status. We'll need to think about this, and 
yes, any behavior change would require a CSR and release note.

PipeInputStream/PipeOutpuStream/PipeReader/PipeWriter have a lot of issues. Dr. 
Deprecator has been salivating over these classes for a long time.  It might 
that the right thing is to not touch the implementation but instead just 
deprecate these as these are broken (and unfixable) for so many reasons.

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

PR Comment: https://git.openjdk.org/jdk/pull/27941#issuecomment-3435844630

Reply via email to