8025619: (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed

[Alan Bateman]

On 27/11/2014 00:35, Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8025619
> Patch:	http://cr.openjdk.java.net/~bpb/8025619/webrev.00/
>
> This patch fixes the immediate problem encountered by the test included in the issue description. The fix is simply for FileKey.create() to throw an IOException directly instead of wrapping it in an Error.
>
> This raises the question of whether some additional verbiage in the description of getChannel() might be necessary to remind that calling close() on the source object will render the FileChannel inviable and possibly cause unforeseen subsequent exceptions.
>
> Also, as noted in the issue comments, it begs the question as to whether getChannel() in FileInputStream, FileOutputStream, RendomAccessFile, etc., should return null or throw an IOException if the object on which it is invoked has already been closed. If so this would need to be addressed by an issue yet to be filed and would imply a documentation change.
>
>
I don't think the fix is right, consider for example what would happen 
if the file descriptor is recycled to another file before tryLock is called.

One way to fix this would be to create the FileChannel in getChannel 
immediately close it (so that FileChannel doesn't leak out in the open 
state). This will need a bit of work in implCloseChannel, one idea is to 
have it be a no-op if !fs.valid().

-Alan.