Closed
Description
I'm seeing this in LogbackLoggingSystemTests
but it could happen in any test that sets java.io.tmpdir
. The pollution happens like this:
- A test's setup code sets
java.io.tmpdir
to a JUnit-provided temporary directory - Some code, a call to
Files.createTempFile
for example, causesjava.io.File.TempDirectory
to be loaded and itstmpdir
static
is set to the value ofjava.io.tmpdir
- A test's cleanup code restores
java.io.tmpdir
to its original value and JUnit deletes its temporary directory - Some code tries to use
Files.createTempFile
and it fails becausejava.io.File.TempDirectory.tmpdir
points to the directory that was deleted in step 3
Ideally, we'd avoid setting java.io.tmpdir
in our tests. Failing that, we could ensure that java.io.File.TempDirectory
has been initialized before we set it so that its tmpdir
static doesn't get polluted with a custom directory that may only exist for the duration of a single test.
There's a similar problem with java.nio.file.TempFileHelper.tmpdir
that's used by java.nio.file.Files.createTempFile(String, String, FileAttribute<?>...)