@matthiasblaesing Depends on the specific piece of code we are talking about. For JarClassLoader, as an example, it could come from anywhere, in client code that we don't control, for instance in a NetBeans plugin or a platform application--or simply other IDE modules that shouldn't need to change as a result of this change. For instance, a task running in an interruptible RequestProcessor may receive an interrupt if RequestProcessor.cancel() is called while the task is running (and if this is enabled in the RequestProcessor's constructor).
> Being able to intercept for example class loading over a broken URL (with an > unresponsive host for example), sounds like an improvement. Yes, absolutely. That's why RequestProcessor supports this, for instance. But for this to work, the each piece of possibly-interruptible code must be reviewed and/or changed to make sure the interrupted case is handled specially. For example, in the JarClassLoader case, we could theoretically do the same as when the class is not found at all--but what if higher-level code then caches this negative result, and decides never to try to load that class again? That would be bad if the interruption happened simply because the I/O operation was taking a little bit of time. And these kinds of bugs would be very hard to track down, since they would only happen every once in a while, basically at random. The only safe thing to do, absent an API that explicitly says "the result of this method should not be cached" or "this method may throw an InterruptedException", is to force the request to finish despite the interrupt, but then making sure to leave the thread interrupt bit on before returning. That's what the old FileInputStream/FileOutputStream did. [ Full content available at: https://github.com/apache/incubator-netbeans/pull/854 ] This message was relayed via gitbox.apache.org for [email protected]
