RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Sergey Bylokhov]

As far as I understand this new temp folder will be cleaned after every
tests run, doesn't it look like a workaround for problematic tests and
product bugs?
Personally, I found many bugs in the tests and some product bugs as
well, which caused "leakage" of the temporary files.

Probably additionally to this fix we should personalise every temp
file created in the test context via createTempFile or similar API and
report the test as failed if the file was not removed at the end?

On 6/16/20 3:53 pm, Jonathan Gibbons wrote:
> It would also be good to identify the tests that are using temporary directories in this manner and have them use the jtreg scratch directory where possible.
> 
> -- Jon
> 
> On 6/16/20 12:22 PM, Erik Joelsson wrote:
>> (re-sending this as it doesn't look like it was delivered)
>>
>> There are a lot of jtreg tests that use temporary files. These temporary files add up over time and fill up the global temp directories on our test systems. To tackle this, we should try to redirect these temporary files into a directory controlled by the test framework. Jtreg does not do this, but we can set -Djava.io.tmpdir from RunTest.gmk. This will not prevent all temp files from being created outside of the work dir, but at least most.
>>
>>
>> I have found one test where this becomes an issue, java/nio/file/Path/Misc.java on Windows when running in elevated mode with the workspace on a subst drive. This looks like an actual issue in the product, so I have filed a separate bug for it [1]. Since we currently use subst in our distributed test system to get around Windows path length issues, we are hitting this problem. While the bug is being evaluated, I have implemented a workaround in the test so that it is able to handle the known situation. I would like to have someone from core-libs look at the workaround.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8213214/webrev.01/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213214
>>
>> /Erik
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8213216
>>
>>


-- 
Best regards, Sergey.