RFR: 8370387: Remove handling of InterruptedIOException from java.io classes

Alan Bateman alanb at openjdk.org
Thu Oct 23 09:04:14 UTC 2025


On Wed, 22 Oct 2025 18:26:16 GMT, Brian Burkhalter <bpb at openjdk.org> 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


More information about the core-libs-dev mailing list