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

Alan Bateman Alan.Bateman at oracle.com
Tue Dec 9 08:14:48 UTC 2014


On 08/12/2014 22:28, Brian Burkhalter wrote:
> :
>
> Here’s an updated patch incorporating the foregoing suggested changes:
>
> http://cr.openjdk.java.net/~bpb/8025619/webrev.02/ 
> <http://cr.openjdk.java.net/%7Ebpb/8025619/webrev.02/>
>
>
This looks better except for getChannel which isn't right in this 
iteation. I think it's best to change this to use the double-checked 
locking idiom, this will give something like:

FileChannel fc = this.channel;
if (fc == null) {
     synchornized (this) {
         fc = this.channel;
         if (fc == null) {
             this.channel = fc = FileChannelImpl.open(...);
             :
         }
     }
}
return fc;

A minor comment but you can drop the initializing of channel to null (to 
avoid a needless volatile write).

In close then you can eliminate a volatile-read with FileChannel fc = 
channel; if (fc != null) fc.close();

In the test then it would be good to assert !fc.isOpen();  The tryLock 
is still a bit odd, shouldn't that be checking for 
ClosedChannelException too? An alternative name for the test is 
GetClosedChannel if you are looking for another name.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20141209/e866a134/attachment.html>


More information about the nio-dev mailing list