Hi All,
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
block. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/
-Dan
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
windows.
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!
Bug:https://bugs.openjdk.java.net/browse/JDK-8028628
Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev/
<http://cr.openjdk.java.net/%7Edxu/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).
-Alan