RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors

[Peter Levart]

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.levart at gmail.com 
> <mailto:peter.levart at 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
>