FileChannel implements InterruptibleChannel, help or hindrance?

[Alan Bateman]

As we all know here, FileChannel implements InterruptibleChannel so it's 
asynchronously closeable and interrupting threads doing I/O operations 
on a file channel cause it to be closed.

I've never been comfortable with the FileChannel being closed by 
Thread.interrupt and I'm wondering whether it would be worth providing a 
way for file I/O operations to not being interruptible. A case in point 
is class loading from the jimage container file, another is class 
loading from modules exploded on the file system. The former hacks into 
FileChannel implementation to prevent closing and spurious 
NoClassDefFoundErrors, the latter is pondering doing the same. We also 
have Files.readAllBytes and Files.newXXXStream ultimately using a 
FileChannel where a thread interrupt might cause usage to fail with 
ClosedByInterruptException.

One potential approach is to add an OpenOption (maybe 
StandardOpenOption.UNINTERRUPTIBLE) that can be specified to 
FileChannel.open. This seem preferable to providing a way to toggle 
interruptibility dynamically, esp. in cases where a FileChannel is used 
by several concurrent threads. There are wider scope ways to do this too 
but it would mean re-visiting InterruptibleChannel and its base 
implementation in the spi package with potential knock on impact in 
other areas of the API.

-Alan