On 01/01/2015 08:56 PM, Chris Hegarty wrote:
This looks very nice Peter.
Just a small comment on the test; it may avoid future problems if the
test use deleteFileWithRetry, from the test library [1], rather than
file.delete().
-Chris.
[1]
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/lib/testlibrary/jdk/testlibrary/FileUtils.java
Hi Chris,
Thanks for pointing me to the FileUtils. It got me thinking that the
test might not be able to delete the file on Windows, since after return
from 2nd call to testCaching(), it might still be open (and it very
probably will be in the webrev.04 test).
So I "fixed" this. I now treat the unsuccessful deletion as a test
failure as it should only occur if the file is not closed at the end
which it now should be.
Here's the latest webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.05/
Regards, Peter
On 1 Jan 2015, at 19:21, Peter Levart <peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>> wrote:
On 12/29/2014 04:51 PM, Alan Bateman wrote:
On 29/12/2014 09:45, Peter Levart wrote:
Thanks for looking at this, Alan.
You're right about File.getCanonicalFile(). It already checks read
permission for a file. The additional explicit check is
superfluous. I have removed it.
With explicit check I wanted the API to behave uniformly regardless
of whether the returned stream is opened by getInputStream() call
or an already opened stream is just returned. getCannonicalFile()
already takes care of it. Here's the updated webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/
Updated patch looks good to me.
-Alan.
Thanks, Alan.
Peter
