RFR: 8370387: Remove handling of InterruptedIOException from java.io classes
Pavel Rappo
prappo at openjdk.org
Thu Oct 23 09:00:01 UTC 2025
On Thu, 23 Oct 2025 02:27:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> For some classes you are now leaving the interrupt state set, rather than clearing it as before. Such a behaviour change definitely needs a CSR request.
There's this duality between interrupted status and InterruptedException. When code detects the interrupted status is set, it may clear it and then throw InterruptedException. Likewise, if code catches InterruptedException, it may set the interrupted status.
I think, Interrupted-IO-Exception kinda tries to be like that: it behaves as if it had the same semantics in regard to interrupted status. However, it never specified this semantics. Come to think of it, I don't think any exception other than InterruptedException has this semantics. For example, ClosedByInterruptException and FileLockInterruptionException do not. They are thrown with the interrupted status set.
> You also potentially break code that catches `InterruptedIOException`.
It might be helpful to see how Interrupted-IO-Exception is handled in the wild. I would be surprised if any significant portion of clients handled it as if it was InterruptedException. To me Interrupted-IO-Exception is a "swallowed" interruption.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/27941#issuecomment-3435825183
More information about the core-libs-dev
mailing list