8205612: (fc) Files.readAllBytes fails with ClosedByInterruptException when interrupt status set

Alan Bateman Alan.Bateman at oracle.com
Mon Jun 25 15:40:27 UTC 2018

I brought up the problems with FileChannel implementing 
InterruptibleChannel a few months ago but we didn't make progress on 
agreeing an API change at the time.

In the mean-time, "simple APIs" such as Files.readAllBytes(...), 
Files.newInputStream(...).read(...) and other fail with 
ClosedByInterruptException when called with the interrupt status set. 
Another example is class loading from exploding modules and that also 
makes use of FileChannel under the covers too.

I'd like to put in an interim solution so that the simple APIs can use 
FileChannel without being concerned about the interrupt status. The 
changes mean InputStream, OutputStream, BufferedReader, and 
BufferedWriter objects obtained from the default provider are 
non-interruptible. Simple APIs such as readString, readAllBytes, lines, 
... will also be non-interruptible. APIs that expose channels are not 
impacted, this will be continue to be interruptible.

The changes are very simple. We also had some of this in place already 
for the jimage code (as it uses FileChannel when configured not to mmap 
the jimage file).



More information about the nio-dev mailing list