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