RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
dan.xu at oracle.com
Thu Nov 21 01:09:02 UTC 2013
I have updated my fix based on your suggestions. I have changed to
create testing files in the working directory, moved those static member
variables into local method variables, and used try-with-resources to
read and write the testing files. After the change, the file delete is
no longer important. So I just do the clean-up with deleteOnExit() for
simplicity. If the test fails, it is better to keep the test file to
give more clue. Therefore, I don't put the file clean-up into finally
On 11/20/2013 04:08 AM, Alan Bateman wrote:
> On 19/11/2013 23:57, Dan Xu wrote:
>> Hi All,
>> Please review the simple fix towards Size.java testcase. It failed
>> once on windows platform in the recent same binary run, which is
>> mostly due to some interferences and the special delete handling on
>> In the fix, I remove the delete operation in initTestFile() method
>> because FileOutputStream will truncate the file content and it is not
>> necessary to delete it first. Thanks!
>> Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/
> This does look like a case where the test is needlessly deleting and
> re-creating the file (although still annoying to have interference
> from virus checkers or other background services). As you point out,
> FileOutputStream will truncate an existing file so it's not needed. So
> I think your changes to remove the exist/delete from the init method
> is good.
> If you have the cycles then there are probably a few clean-ups that
> could be done on this test. I don't think blah needs to be static, it
> could use try-with-resources and delete blah in the finally block.
> Also test2 looks historical, it may be that this can be enabled on
> Linux and Windows now (the bug/comments seem to date from JDK 1.4).
More information about the core-libs-dev