On Thu, 23 Oct 2025 02:27:03 GMT, Brian Burkhalter <[email protected]> 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
