-
Bug
-
Resolution: Won't Fix
-
P3
-
24
Similar to how we handle java.io.tmpdir in JDK-8213214, we should also override "user.home". There are multiple reasons for this.
1. Tests should not litter in global directories. Any test output should be confined to locations we control as far as possible.
2. Tests should not be affected by any local user configuration. If a test is using anything from the user's actual home directory, there is a risk that local user configurations could affect the test outcome.
3. Interference between parallel test runs. If tests use global directories, there is a chance that the same test running multiple times in parallel could affect each other.
4. In a distributed test scenario, the user home directory could be read-only. This is basically a special case of 2.
While experimenting with running tests in situation 4, I found two tests in tier1 that fail with a read only user home:
jdk/jshell/ToolProviderTest.java
jdk/jshell/TerminalNoExecTest.java
I believe the reason here, at least in one of them, is java.util.prefs, but that's not really important.
My proposed solution is to just create a `test-support/user` directory in RunTests.gmk and set `-Duser.home=test-support/user` just like we do for java.io.tmpdir. I'm going to run this patch through every relevant tier before posting the review.
The main complication that I could imagine would be if we have a test for the actual default population of user.home (or java.io.tmpdir) system properties. Such a test would need to take extra steps to ensure it's not tainted by the proposed -D flags.
1. Tests should not litter in global directories. Any test output should be confined to locations we control as far as possible.
2. Tests should not be affected by any local user configuration. If a test is using anything from the user's actual home directory, there is a risk that local user configurations could affect the test outcome.
3. Interference between parallel test runs. If tests use global directories, there is a chance that the same test running multiple times in parallel could affect each other.
4. In a distributed test scenario, the user home directory could be read-only. This is basically a special case of 2.
While experimenting with running tests in situation 4, I found two tests in tier1 that fail with a read only user home:
jdk/jshell/ToolProviderTest.java
jdk/jshell/TerminalNoExecTest.java
I believe the reason here, at least in one of them, is java.util.prefs, but that's not really important.
My proposed solution is to just create a `test-support/user` directory in RunTests.gmk and set `-Duser.home=test-support/user` just like we do for java.io.tmpdir. I'm going to run this patch through every relevant tier before posting the review.
The main complication that I could imagine would be if we have a test for the actual default population of user.home (or java.io.tmpdir) system properties. Such a test would need to take extra steps to ensure it's not tainted by the proposed -D flags.