RFR: JDK-8047769 SecureRandom should be more frugal with file descriptors
peter.levart at gmail.com
Thu Jan 1 20:57:18 UTC 2015
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 , rather than
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:
> 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:
>>> Updated patch looks good to me.
>> Thanks, Alan.
More information about the core-libs-dev