[GitHub] eirikbakke edited a comment on issue #854: [NETBEANS-1197] Avoid ClosedByInterruptException in JarClassLoader

[GitBox <gi...@apache.org>]

eirikbakke edited a comment on issue #854: [NETBEANS-1197] Avoid ClosedByInterruptException in JarClassLoader
URL: https://github.com/apache/incubator-netbeans/pull/854#issuecomment-423650130
 
 
   @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.
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@netbeans.apache.org
For additional commands, e-mail: notifications-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists